SSL হ্যান্ডশেক ব্যর্থতা - খারাপ ক্লায়েন্ট সার্টিফিকেট

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশনটি একটি API অনুরোধের প্রতিক্রিয়া হিসাবে "পরিষেবা অনুপলব্ধ" বার্তা সহ 503- এর একটি HTTP স্ট্যাটাস কোড পায়। UI ট্রেসে, আপনি লক্ষ্য করবেন যে error.cause টি Received fatal alert: bad_certificate ।

আপনার যদি মেসেজ প্রসেসর লগগুলিতে অ্যাক্সেস থাকে, তাহলে আপনি Received fatal alert: bad_certificate । এই ত্রুটিটি বার্তা প্রসেসর এবং ব্যাকএন্ড সার্ভারের মধ্যে 2 উপায়ে TLS সেটআপের মধ্যে SSL হ্যান্ডশেক প্রক্রিয়ার সময় পরিলক্ষিত হয়।

ত্রুটি বার্তা

ক্লায়েন্ট অ্যাপ্লিকেশন নিম্নলিখিত প্রতিক্রিয়া কোড পায়:

HTTP/1.1 503 Service Unavailable

উপরন্তু, আপনি নিম্নলিখিত ত্রুটি বার্তা পর্যবেক্ষণ করতে পারেন:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

ব্যক্তিগত ক্লাউড ব্যবহারকারীরা মেসেজ প্রসেসর লগ /opt/apigee/var/log/edge-message-processor/system.log এ নির্দিষ্ট API অনুরোধের জন্য নিম্নলিখিত ত্রুটি দেখতে পাবেন:

2017-10-23 05:28:57,813 org: org-name env: env-name api: apiproxy-name rev: revision-number messageid: message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C: IP address : port # Remote host: IP address : port # ]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed , message: Received fatal alert: bad_certificate

সম্ভাব্য কারণ

এই সমস্যার সম্ভাব্য কারণগুলি নিম্নরূপ:

কারণ বর্ণনা এর জন্য প্রযোজ্য সমস্যা সমাধানের নির্দেশাবলী
ক্লায়েন্ট সার্টিফিকেট নেই টার্গেট সার্ভারের টার্গেট এন্ডপয়েন্টে ব্যবহৃত কীস্টোরের কোনো ক্লায়েন্ট সার্টিফিকেট নেই। এজ প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারী
শংসাপত্র কর্তৃপক্ষের অমিল বার্তা প্রসেসরের কীস্টোরে পাতার শংসাপত্রের শংসাপত্র কর্তৃপক্ষ (সার্টিফিকেট চেইনের প্রথম শংসাপত্র) ব্যাকএন্ড সার্ভার দ্বারা গৃহীত কোনো শংসাপত্র কর্তৃপক্ষের সাথে মেলে না। এজ প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারী

সাধারণ রোগ নির্ণয়ের পদক্ষেপ

  1. এজ UI-তে ট্রেস সক্ষম করুন, API কল করুন এবং সমস্যাটি পুনরুত্পাদন করুন।
  2. UI ট্রেস ফলাফলে, প্রতিটি পর্যায়ে নেভিগেট করুন এবং কোথায় ত্রুটি ঘটেছে তা নির্ধারণ করুন। টার্গেট রিকোয়েস্ট ফ্লোতে ত্রুটি ঘটেছে।
  3. ত্রুটিটি দেখায় এমন ফ্লো পরীক্ষা করুন, নীচের উদাহরণের ট্রেসে দেখানো হিসাবে আপনার ত্রুটিটি পর্যবেক্ষণ করা উচিত:

    alt_text

  4. আপনি উপরের স্ক্রিনশটটিতে দেখতে পাচ্ছেন, error.cause হল "প্রাপ্ত মারাত্মক সতর্কতা: bad_certificate"।
  5. আপনি যদি ব্যক্তিগত ক্লাউড ব্যবহারকারী হন, তাহলে নিচের নির্দেশাবলী অনুসরণ করুন:
    1. আপনি ট্রেসে AX দ্বারা নির্দেশিত ফেজে ত্রুটি হেডার " X-Apigee.Message-ID " এর মান নির্ধারণ করে ব্যর্থ API অনুরোধের জন্য বার্তা আইডি পেতে পারেন৷
    2. মেসেজ প্রসেসর লগ /opt/apigee/var/log/edge-message-processor/system.log এ এই বার্তা আইডি খুঁজুন এবং আপনি ত্রুটি সম্পর্কে আরও তথ্য পেতে পারেন কিনা তা নির্ধারণ করুন:
      2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

      বার্তা প্রসেসর লগে ত্রুটির জন্য একটি স্ট্যাক ট্রেস ছিল Received fatal alert: bad_certificate , কিন্তু এই সমস্যার কারণ নির্দেশ করে এমন কোনো তথ্য নেই।

  6. এই সমস্যাটি আরও তদন্ত করতে, আপনাকে tcpdump টুল ব্যবহার করে TCP/IP প্যাকেটগুলি ক্যাপচার করতে হবে।
    1. আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন, তাহলে আপনি ব্যাকএন্ড সার্ভার বা বার্তা প্রসেসরে TCP/IP প্যাকেটগুলি ক্যাপচার করতে পারেন। প্যাকেটগুলি ব্যাকএন্ড সার্ভারে ডিক্রিপ্ট করা হয় বলে ব্যাকএন্ড সার্ভারে তাদের ক্যাপচার করুন।
    2. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে ব্যাকএন্ড সার্ভারে TCP/IP প্যাকেটগুলি ক্যাপচার করুন৷
    3. একবার আপনি TCP/IP প্যাকেটগুলি কোথায় ক্যাপচার করতে চান তা ঠিক করে নিলে, TCP/IP প্যাকেটগুলি ক্যাপচার করতে নীচের tcpdump কমান্ডটি ব্যবহার করুন। 
      4. tcpdump -i any -s 0 host <IP address> -w <File name>

      আপনি যদি বার্তা প্রসেসরে TCP/IP প্যাকেটগুলি নিচ্ছেন, তাহলে tcpdump কমান্ডে ব্যাকএন্ড সার্ভারের সর্বজনীন IP ঠিকানা ব্যবহার করুন।

      যদি ব্যাকএন্ড সার্ভার/মেসেজ প্রসেসরের জন্য একাধিক আইপি ঠিকানা থাকে, তাহলে আপনাকে একটি ভিন্ন tcpdump কমান্ড ব্যবহার করতে হবে। এই টুল সম্পর্কে আরও তথ্যের জন্য এবং এই কমান্ডের অন্যান্য রূপের জন্য tcpdump পড়ুন।

  7. Wireshark টুল বা অনুরূপ টুল ব্যবহার করে TCP/IP প্যাকেট বিশ্লেষণ করুন যার সাথে আপনি পরিচিত।

এখানে Wireshark টুল ব্যবহার করে নমুনা TCP/IP প্যাকেট ডেটার বিশ্লেষণ করা হল:

alt_text

  1. উপরের tcpdump-এ বার্তা #4 দেখায় যে মেসেজ প্রসেসর (উৎস) ব্যাকএন্ড সার্ভারে (গন্তব্য) একটি "ক্লায়েন্ট হ্যালো" বার্তা পাঠিয়েছে।
  2. বার্তা #5 দেখায় যে ব্যাকএন্ড সার্ভার মেসেজ প্রসেসর থেকে ক্লায়েন্ট হ্যালো বার্তা স্বীকার করে।
  3. ব্যাকএন্ড সার্ভার তার সার্টিফিকেট সহ "সার্ভার হ্যালো" বার্তা পাঠায় এবং তারপর ক্লায়েন্টকে বার্তা #7-এ তার শংসাপত্র পাঠাতে অনুরোধ করে।
  4. বার্তা প্রসেসর শংসাপত্রের যাচাইকরণ সম্পূর্ণ করে এবং বার্তা #8-এ ব্যাকএন্ড সার্ভারের সার্ভারহ্যালো বার্তাটি স্বীকার করে।
  5. মেসেজ প্রসেসর তার সার্টিফিকেট পাঠায় ব্যাকএন্ড সার্ভারে মেসেজ #9 এ।
  6. ব্যাকএন্ড সার্ভার বার্তা #11-এ বার্তা প্রসেসরের শংসাপত্রের প্রাপ্তি স্বীকার করে।

  7. যাইহোক, এটি অবিলম্বে একটি মারাত্মক সতর্কতা পাঠায়: বার্তা প্রসেসরে খারাপ শংসাপত্র (বার্তা #12)। এটি নির্দেশ করে যে বার্তা প্রসেসর দ্বারা প্রেরিত শংসাপত্রটি খারাপ ছিল এবং তাই ব্যাকএন্ড সার্ভারে শংসাপত্র যাচাইকরণ ব্যর্থ হয়েছে৷ ফলস্বরূপ, SSL হ্যান্ডশেক ব্যর্থ হয়েছে এবং সংযোগটি বন্ধ হয়ে যাবে।


    alt_text

  8. এখন মেসেজ প্রসেসর দ্বারা প্রেরিত সার্টিফিকেটের বিষয়বস্তু পরীক্ষা করার জন্য বার্তা #9 দেখুন:


    alt_text

  9. আপনি লক্ষ্য করতে পারেন, ব্যাকএন্ড সার্ভারটি ক্লায়েন্টের কাছ থেকে কোনো শংসাপত্র পায়নি ( শংসাপত্রের দৈর্ঘ্য: 0) । তাই, ব্যাকএন্ড সার্ভার মারাত্মক সতর্কতা পাঠায়: খারাপ শংসাপত্র।
  10. সাধারণত এটি ঘটে যখন ক্লায়েন্ট, অর্থাৎ মেসেজ প্রসেসর (একটি জাভা ভিত্তিক প্রক্রিয়া):
    1. এর কীস্টোরে কোনো ক্লায়েন্ট সার্টিফিকেট নেই, বা;
    2. এটি একটি ক্লায়েন্ট সার্টিফিকেট পাঠাতে অক্ষম৷ এটি ঘটতে পারে যদি এটি একটি শংসাপত্র খুঁজে না পায় যা ব্যাকএন্ড সার্ভারের একটি গ্রহণযোগ্য শংসাপত্র কর্তৃপক্ষ দ্বারা জারি করা হয়। অর্থ, যদি ক্লায়েন্টের লিফ সার্টিফিকেটের সার্টিফিকেট অথরিটি (অর্থাৎ, চেইনের প্রথম সার্টিফিকেট) ব্যাকএন্ড সার্ভারের গ্রহণযোগ্য সার্টিফিকেট কর্তৃপক্ষের সাথে মেলে না, তাহলে মেসেজ প্রসেসর সার্টিফিকেট পাঠাবে না।

আসুন নীচের হিসাবে এই প্রতিটি কারণ আলাদাভাবে তাকান.

কারণ: ক্লায়েন্ট সার্টিফিকেট নেই

রোগ নির্ণয়

টার্গেট এন্ডপয়েন্ট বা টার্গেট এন্ডপয়েন্টে ব্যবহৃত টার্গেট সার্ভারের SSL ইনফো বিভাগে নির্দিষ্ট করা কীস্টোরে যদি কোনো শংসাপত্র না থাকে, তাহলে এই ত্রুটির কারণ এটি।

এটি কারণ কিনা তা নির্ধারণ করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:

  1. নিচের ধাপগুলি ব্যবহার করে নির্দিষ্ট API প্রক্সির জন্য টার্গেট এন্ডপয়েন্ট বা টার্গেট সার্ভারে ব্যবহৃত কীস্টোর নির্ধারণ করুন:
    1. টার্গেট এন্ডপয়েন্ট বা টার্গেট সার্ভারে SSLInfo বিভাগে কীস্টোর উপাদান থেকে কীস্টোর রেফারেন্স নাম পান।

      আসুন লক্ষ্য এন্ডপয়েন্ট কনফিগারেশনের একটি নমুনা SSLInfo বিভাগে দেখি:

      <SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
    2. উপরের উদাহরণে, কীস্টোর রেফারেন্স নামটি হল " myKeystoreRef"।
    3. এজ UI এ যান এবং API প্রক্সি -> এনভায়রনমেন্ট কনফিগারেশন নির্বাচন করুন।

      রেফারেন্স ট্যাবটি নির্বাচন করুন এবং কীস্টোর রেফারেন্স নামটি অনুসন্ধান করুন। নির্দিষ্ট কীস্টোর রেফারেন্সের জন্য রেফারেন্স কলামে নামটি নোট করুন। এটি আপনার কীস্টোর নাম হবে।


      alt_text

    4. উপরের উদাহরণে, আপনি লক্ষ্য করতে পারেন যে myKeystoreRef-এ "myKeystore" এর রেফারেন্স রয়েছে। অতএব, কীস্টোরের নাম হল myKeystore.
  2. এই কীস্টোরে এজ UI ব্যবহার করে শংসাপত্র রয়েছে কিনা বা কীস্টোর API-এর জন্য তালিকা শংসাপত্র রয়েছে কিনা তা পরীক্ষা করুন৷
  3. যদি কীস্টোরে সার্টিফিকেট(গুলি) থাকে, তাহলে Cause-এ যান: সার্টিফিকেট অথরিটি মিসম্যাচ ।
  4. যদি কীস্টোরে কোনো শংসাপত্র না থাকে, তাহলে সেই কারণেই ক্লায়েন্ট সার্টিফিকেট মেসেজ প্রসেসর দ্বারা পাঠানো হয় না।

রেজোলিউশন

  1. নিশ্চিত করুন যে সঠিক এবং সম্পূর্ণ ক্লায়েন্ট সার্টিফিকেট চেইনটি মেসেজ প্রসেসরের নির্দিষ্ট কীস্টোরে আপলোড করা হয়েছে।

কারণ: সার্টিফিকেট অথরিটি অমিল

সাধারণত যখন সার্ভার ক্লায়েন্টকে তার শংসাপত্র পাঠাতে অনুরোধ করে, তখন এটি স্বীকৃত ইস্যুকারী বা শংসাপত্র কর্তৃপক্ষের সেট নির্দেশ করে। যদি বার্তা প্রসেসরের কীস্টোরে পাতার শংসাপত্রের ইস্যুকারী/শংসাপত্র কর্তৃপক্ষ (অর্থাৎ, সার্টিফিকেট চেইনের প্রথম শংসাপত্র) ব্যাকএন্ড সার্ভার দ্বারা গৃহীত কোনো শংসাপত্র কর্তৃপক্ষের সাথে মেলে না, তাহলে বার্তা প্রসেসর (যা একটি জাভা ভিত্তিক প্রক্রিয়া ) ব্যাকএন্ড সার্ভারে সার্টিফিকেট পাঠাবে না।

এটি যদি হয় তা নিশ্চিত করতে নীচের পদক্ষেপগুলি ব্যবহার করুন:

  1. কীস্টোর API-এর জন্য তালিকা শংসাপত্র ।
  2. কীস্টোর API-এর জন্য গেট সার্টিফিকেট ব্যবহার করে উপরের ধাপ #1 এ প্রাপ্ত প্রতিটি শংসাপত্রের বিশদ বিবরণ পান।
  3. কীস্টোরে সংরক্ষিত লিফ সার্টিফিকেট (অর্থাৎ, সার্টিফিকেট চেইনের প্রথম শংসাপত্র) প্রদানকারীকে নোট করুন।

    নমুনা পাতা শংসাপত্র

    {
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

    উপরের উদাহরণে, ইস্যুকারী/শংসাপত্র কর্তৃপক্ষ হল "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

  4. নিম্নলিখিত কৌশলগুলির মধ্যে একটি ব্যবহার করে ব্যাকএন্ড সার্ভারের ইস্যুকারী বা শংসাপত্র কর্তৃপক্ষের স্বীকৃত তালিকা নির্ধারণ করুন:

    কৌশল #1: নিচের openssl কমান্ড ব্যবহার করুন:

    openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>

    নীচে দেখানো হিসাবে এই কমান্ডের আউটপুটে "গ্রহণযোগ্য ক্লায়েন্ট সার্টিফিকেট CA নাম" শিরোনামের বিভাগটি পড়ুন:

    Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com

    কৌশল #2: TCP/IP প্যাকেটে Certificate Request প্যাকেট পরীক্ষা করুন, যেখানে ব্যাকএন্ড সার্ভার ক্লায়েন্টকে তার শংসাপত্র পাঠাতে অনুরোধ করে:

    উপরে দেখানো নমুনা TCP/IP প্যাকেটগুলিতে, Certificate Request প্যাকেট হল বার্তা #7। "বিশিষ্ট নাম" বিভাগটি পড়ুন, যেখানে ব্যাকএন্ড সার্ভারের গ্রহণযোগ্য শংসাপত্র কর্তৃপক্ষ রয়েছে।

    alt_text

  5. ধাপ #3 এ প্রাপ্ত শংসাপত্র কর্তৃপক্ষ ব্যাকএন্ড সার্ভারের স্বীকৃত ইস্যুকারী বা ধাপ #4 এ প্রাপ্ত শংসাপত্র কর্তৃপক্ষের তালিকার সাথে মেলে কিনা তা যাচাই করুন। যদি কোনো মিল না থাকে, তাহলে বার্তা প্রসেসর ব্যাকএন্ড সার্ভারে ক্লায়েন্ট সার্টিফিকেট পাঠাবে না।

    উপরের উদাহরণে, আপনি লক্ষ্য করতে পারেন যে মেসেজ প্রসেসরের কীস্টোরে ক্লায়েন্টের লিফ সার্টিফিকেট প্রদানকারী ব্যাকএন্ড সার্ভারের স্বীকৃত শংসাপত্র কর্তৃপক্ষের সাথে মেলে না। তাই, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে ক্লায়েন্ট সার্টিফিকেট পাঠায় না। এর ফলে SSL হ্যান্ডশেক ব্যর্থ হয় এবং ব্যাকএন্ড সার্ভার " Fatal alert: bad_certificate " বার্তা পাঠায়।

রেজোলিউশন

  1. ইস্যুকারী/শংসাপত্র কর্তৃপক্ষের সাথে শংসাপত্রটি নিশ্চিত করুন যা ক্লায়েন্টের লিফ সার্টিফিকেটের ইস্যুকারী/শংসাপত্র কর্তৃপক্ষের সাথে মেলে (শৃঙ্খলে প্রথম শংসাপত্র) ব্যাকএন্ড সার্ভারের ট্রাস্টস্টোরে সংরক্ষণ করা হয়েছে।
  2. এই প্লেবুকে বর্ণিত উদাহরণে, ইস্যুকারী "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" ব্যাকএন্ডে যোগ করা হয়েছে সমস্যা সমাধানের জন্য সার্ভারের ট্রাস্টস্টোর।

যদি সমস্যাটি এখনও থেকে যায়, তাহলে অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন- এ যান।

ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে

উপরের নির্দেশাবলী অনুসরণ করার পরেও যদি সমস্যাটি থেকে যায়, অনুগ্রহ করে নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন। এপিজি এজ সাপোর্টে যোগাযোগ করুন এবং শেয়ার করুন:

  1. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
    1. প্রতিষ্ঠানের নাম
    2. পরিবেশের নাম
    3. API প্রক্সি নাম
    4. ত্রুটিটি পুনরুত্পাদন করতে কার্ল কমান্ডটি সম্পূর্ণ করুন
    5. ট্রেস ফাইল ত্রুটি দেখাচ্ছে
    6. TCP/IP প্যাকেট ব্যাকএন্ড সার্ভারে ক্যাপচার করা হয়েছে
  2. আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন তবে নিম্নলিখিত তথ্য প্রদান করুন:
    1. সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত
    2. API প্রক্সি বান্ডেল
    3. ট্রেস ফাইল ত্রুটি দেখাচ্ছে
    4. বার্তা প্রসেসর লগ /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. TCP/IP প্যাকেটগুলি ব্যাকএন্ড সার্ভার বা মেসেজ প্রসেসরে ক্যাপচার করা হয়েছে।
    6. কীস্টোর API-এর জন্য শংসাপত্র পান এর আউটপুট।
  3. আপনি এই প্লেবুকের কোন বিভাগগুলি চেষ্টা করেছেন এবং অন্য কোন অন্তর্দৃষ্টি যা আমাদের এই সমস্যার দ্রুত সমাধান করতে সাহায্য করবে সে সম্পর্কে বিশদ বিবরণ।