SSL হ্যান্ডশেক সংক্রান্ত সমস্যা - ক্লায়েন্ট সার্টিফিকেট ঠিক নেই

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

সমস্যার উপসর্গ

API অনুরোধের উত্তরে ক্লায়েন্ট অ্যাপ্লিকেশন 503 HTTP স্ট্যাটাস কোড সহ "পরিষেবা উপলভ্য নেই" মেসেজ পায়। UI ট্রেসে, আপনি লক্ষ্য করবেন যে error.cause হল Received fatal alert: bad_certificate API অনুরোধ ব্যর্থ হওয়ার জন্য টার্গেট রিকোয়েস্ট ফ্লোতে ।

আপনার কাছে মেসেজ প্রসেসর লগ অ্যাক্সেস করার সুবিধা থাকলে, আপনি API অনুরোধ ব্যর্থ হওয়ার জন্য Received fatal alert: bad_certificate হিসেবে সমস্যার মেসেজ দেখতে পাবেন। ২-ওয়ে TLS সেট-আপে মেসেজ প্রসেসর ও ব্যাকএন্ড সার্ভারের মধ্যে SSL হ্যান্ডশেক প্রসেস চলাকালীন এই সমস্যা দেখা যায়।

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

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

HTTP/1.1 503 Service Unavailable

এছাড়াও, আপনি নিম্নলিখিত সমস্যার মেসেজ দেখতে পেতে পারেন:

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

প্রাইভেট ক্লাউড ব্যবহারকারীরা নির্দিষ্ট API অনুরোধের জন্য মেসেজ প্রসেসর লগে /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

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

এই সমস্যার সম্ভাব্য কারণগুলি নিচে উল্লেখ করা হল:

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

সমস্যার সমাধান সংক্রান্ত সাধারণ ধাপ

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

    alt_text

  4. উপরের স্ক্রিনশটে দেখতে পাচ্ছেন যে error.cause হল "Received fatal alert: bad_certificate"।
  5. আপনি প্রাইভেট ক্লাউড ব্যবহারকারী হলে, নিচে উল্লেখ করা নির্দেশাবলী অনুসরণ করুন:
    1. ট্রেসে AX-এর দেখানো ফেজে সমস্যার হেডার "X-Apigee.Message-ID"-এর ভ্যালু নির্ধারণ করে, API অনুরোধ ব্যর্থ হলে তার মেসেজ আইডি পেতে পারেন।
    2. Message Processor লগে এই মেসেজ আইডি সার্চ করুন /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]

      Message Processor লগে সমস্যার জন্য একটি স্ট্যাক ট্রেস 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 অ্যাড্রেস ব্যবহার করুন।

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

  7. Wireshark টুল বা আপনি পরিচিত এমন একই ধরনের টুল ব্যবহার করে TCP/IP প্যাকেট বিশ্লেষণ করুন।

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

alt_text

  1. উপরের tcpdump-এর ৪ নম্বর মেসেজ থেকে দেখা যাচ্ছে যে মেসেজ প্রসেসর (সোর্স) ব্যাকএন্ড সার্ভারে (ডেস্টিনেশন) একটি "ক্লায়েন্ট হ্যালো" মেসেজ পাঠিয়েছে।
  2. মেসেজ #৫ থেকে দেখা যাচ্ছে যে ব্যাকএন্ড সার্ভার, মেসেজ প্রসেসর থেকে আসা ক্লায়েন্ট হ্যালো মেসেজ স্বীকার করেছে।
  3. ব্যাকএন্ড সার্ভার তার সার্টিফিকেট সহ "Server Hello" মেসেজ পাঠায়, এবং তারপর ক্লায়েন্টকে #৭ মেসেজে তার সার্টিফিকেট পাঠাতে অনুরোধ করে।
  4. মেসেজ প্রসেসর সার্টিফিকেট যাচাইকরণ সম্পূর্ণ করে এবং মেসেজ #৮-এ ব্যাকএন্ড সার্ভারের ServerHello মেসেজটি স্বীকার করে।
  5. মেসেজ প্রসেসর মেসেজ #৯-এ ব্যাকএন্ড সার্ভারে তার সার্টিফিকেট পাঠায়।
  6. ব্যাকএন্ড সার্ভার মেসেজ #১১-এ মেসেজ প্রসেসরের সার্টিফিকেট পাওয়ার বিষয়টি স্বীকার করে।
  7. তবে, এটি অবিলম্বে মেসেজ প্রসেসরকে (মেসেজ #১২) একটি মারাত্মক সতর্কতা: ভুল সার্টিফিকেট পাঠায়। এর থেকে বোঝা যায় যে মেসেজ প্রসেসর যে সার্টিফিকেট পাঠিয়েছে সেটি সঠিক নয় এবং সেই কারণে ব্যাকএন্ড সার্ভারে সার্টিফিকেট যাচাইকরণ ব্যর্থ হয়েছে। এর ফলে, SSL হ্যান্ডশেক সম্পূর্ণ করা যায়নি এবং কানেকশন বন্ধ হয়ে যাবে।


    alt_text

  8. মেসেজ প্রসেসর যে সার্টিফিকেট পাঠিয়েছে তার কন্টেন্ট চেক করতে, আসুন এখন মেসেজ #৯ দেখি:


    alt_text

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

আসুন, এইসব কারণের প্রত্যেকটি আলাদা আলাদাভাবে দেখে নেওয়া যাক।

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

ডায়াগনসিস

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

এটিই কারণ কিনা তা নির্ধারণ করতে, নিচে দেওয়া ধাপগুলি অনুসরণ করুন:

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

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

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

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


      alt_text

    4. উপরের উদাহরণে, আপনি লক্ষ্য করতে পারবেন যে myKeystoreRef-এ "myKeystore"-এর রেফারেন্স আছে। তাই, Keystore-এর নাম হল myKeystore.
  2. এই কীস্টোরে Edge UI বা কীস্টোর API-এর জন্য তালিকাভুক্ত সার্টিফিকেট ব্যবহার করে সার্টিফিকেট আছে কিনা তা চেক করুন।
  3. Keystore-এ সার্টিফিকেট থাকলে, কারণ: সার্টিফিকেট অথরিটি ম্যাচ না করা লিঙ্কে যান।
  4. Keystore-এ কোনও সার্টিফিকেট না থাকলে, সেই কারণেই মেসেজ প্রসেসর ক্লায়েন্ট সার্টিফিকেট পাঠায় না।

রেজোলিউশন

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

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

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

এটি হয়েছে কিনা তা কনফার্ম করতে, নিচে দেওয়া ধাপগুলি অনুসরণ করুন:

  1. Keystore API-এর জন্য সার্টিফিকেট তালিকাভুক্ত করুন।
  2. উপরে #১ ধাপে পাওয়া প্রতিটি সার্টিফিকেটের বিবরণ পেতে কিস্টোর API-এর জন্য সার্টিফিকেট পান ব্যবহার করুন।
  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. নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটি ব্যবহার করে ব্যাকএন্ড সার্ভারের ইস্যুকারী বা সার্টিফিকেট কর্তৃপক্ষের গ্রহণযোগ্য তালিকা নির্ধারণ করুন:

    টেকনিক #১: নিচে দেওয়া 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

    পদ্ধতি #২: TCP/IP প্যাকেটে Certificate Request প্যাকেট চেক করুন, যেখানে ব্যাকএন্ড সার্ভার ক্লায়েন্টকে তার সার্টিফিকেট পাঠানোর অনুরোধ করে:

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

    alt_text

  5. ধাপ #৩-এ প্রাপ্ত সার্টিফিকেট অথরিটি, ধাপ #৪-এ প্রাপ্ত ব্যাকএন্ড সার্ভারের অনুমোদিত ইস্যুকারী বা সার্টিফিকেট অথরিটির তালিকার সাথে মিলছে কিনা তা যাচাই করুন। ম্যাচ না করলে, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে ক্লায়েন্ট সার্টিফিকেট পাঠাবে না।

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

রেজোলিউশন

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

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

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

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

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