एसएसएल हैंडशेक की कोशिशें - खराब क्लाइंट सर्टिफ़िकेट

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी

समस्या का ब्यौरा

क्लाइंट ऐप्लिकेशन को एपीआई अनुरोध के जवाब के तौर पर, "सेवा उपलब्ध नहीं है" मैसेज के साथ 503 का एचटीटीपी स्टेटस कोड मिलता है. यूज़र इंटरफ़ेस (यूआई) ट्रेस में, आपको दिखेगा कि जो एपीआई अनुरोध पूरा नहीं हो पाया उसके लिए, टारगेट अनुरोध फ़्लो में error.cause Received fatal alert: bad_certificate है.

अगर आपके पास Message प्रोसेसर के लॉग का ऐक्सेस है, तो आपको एपीआई अनुरोध के असफल होने पर, गड़बड़ी का मैसेज Received fatal alert: bad_certificate के तौर पर दिखेगा. यह गड़बड़ी, मैसेज प्रोसेसर और बैकएंड सर्वर के बीच एसएसएल हैंडशेक प्रोसेस के दौरान, दो तरीके से TLS सेटअप के दौरान दिखती है.

गड़बड़ी संदेश

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

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 में, किसी खास एपीआई अनुरोध के लिए यह गड़बड़ी दिखेगी:

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

संभावित वजहें

इस समस्या की ये वजहें हो सकती हैं:

Cause Description समस्या हल करने वाले निर्देश इन पर लागू होते हैं
कोई क्लाइंट सर्टिफ़िकेट नहीं है टारगेट सर्वर के टारगेट एंडपॉइंट में इस्तेमाल किए गए कीस्टोर में कोई क्लाइंट सर्टिफ़िकेट नहीं है. Edge के निजी और सार्वजनिक क्लाउड उपयोगकर्ता
सर्टिफ़िकेट देने वाली संस्था, मैच नहीं कर रही है Message प्रोसेसर के कीस्टोर में लीफ़ सर्टिफ़िकेट (सर्टिफ़िकेट चेन का पहला सर्टिफ़िकेट) की सर्टिफ़िकेट अथॉरिटी, बैकएंड सर्वर से स्वीकार की गई किसी भी सर्टिफ़िकेट अथॉरिटी से मेल नहीं खाती. Edge के निजी और सार्वजनिक क्लाउड उपयोगकर्ता

गड़बड़ी का पता लगाने का सामान्य तरीका

  1. Edge यूज़र इंटरफ़ेस (यूआई) में ट्रेस चालू करें, एपीआई कॉल करें, और समस्या को फिर से सामने लाएं.
  2. यूज़र इंटरफ़ेस (यूआई) ट्रेस के नतीजों में, हर चरण में नेविगेट करें और तय करें कि गड़बड़ी कहां हुई है. गड़बड़ी, टारगेट अनुरोध फ़्लो में हुई होगी.
  3. गड़बड़ी दिखाने वाले फ़्लो की जांच करें. आपको गड़बड़ी पर ध्यान देना चाहिए, जैसा कि नीचे दिए गए उदाहरण ट्रेस में दिखाया गया है:

    alt_text

  4. जैसा कि ऊपर दिए गए स्क्रीनशॉट में दिख रहा है, error.cause की वजह से, "नुकसान पहुंचाने की चेतावनी मिली: Bad_certificate" है.
  5. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो नीचे दिए गए निर्देशों का पालन करें:
    1. पूरे न होने वाले एपीआई अनुरोध के लिए मैसेज आईडी पाया जा सकता है. ऐसा करने के लिए, ट्रेस में AX से दिखाए गए फ़ेज़ में गड़बड़ी के हेडर "X-Apigee.Message-ID" की वैल्यू तय की जा सकती है.
    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 टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट कैप्चर करना होगा.
    1. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो आपके पास बैकएंड सर्वर या मैसेज प्रोसेसर पर टीसीपी/आईपी पैकेट कैप्चर करने का विकल्प होता है. आम तौर पर, इन्हें बैकएंड सर्वर पर कैप्चर करें, क्योंकि पैकेट बैकएंड सर्वर पर डिक्रिप्ट किए जाते हैं.
    2. अगर आप पब्लिक क्लाउड का इस्तेमाल करते हैं, तो बैकएंड सर्वर पर टीसीपी/आईपी पैकेट कैप्चर करें.
    3. टीसीपी/आईपी पैकेट को कैप्चर करने की जगह तय करने के बाद, टीसीपी/आईपी पैकेट को कैप्चर करने के लिए, नीचे दिए गए tcpdump कमांड का इस्तेमाल करें.
      4. tcpdump -i any -s 0 host <IP address> -w <File name>

      अगर आपको Message प्रोसेसर पर टीसीपी/आईपी पैकेट लेना है, तो tcpdump कमांड में बैकएंड सर्वर के सार्वजनिक आईपी पते का इस्तेमाल करें.

      अगर बैकएंड सर्वर/मैसेज प्रोसेसर के लिए एक से ज़्यादा आईपी पते हैं, तो आपको एक अलग tcpdump कमांड का इस्तेमाल करना होगा. इस टूल और इस निर्देश के दूसरे वैरिएंट के बारे में ज़्यादा जानने के लिए, tcpdump देखें.

  7. Wireshark टूल या इसी तरह के दूसरे टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट का विश्लेषण करें.

यहां वायर शार्क टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट डेटा के सैंपल का विश्लेषण दिया गया है:

alt_text

  1. ऊपर दिए गए tcpdump के मैसेज #4 से पता चलता है कि मैसेज प्रोसेसर (सोर्स) ने बैकएंड सर्वर (डेस्टिनेशन) पर एक "Client Hello" मैसेज भेजा है.
  2. मैसेज #5 दिखाता है कि बैकएंड सर्वर, Message प्रोसेसर से मिला क्लाइंट हैलो मैसेज स्वीकार करता है.
  3. बैकएंड सर्वर, अपने सर्टिफ़िकेट के साथ "सर्वर हेलो" मैसेज भेजता है. इसके बाद, क्लाइंट से मैसेज #7 में सर्टिफ़िकेट भेजने का अनुरोध करता है.
  4. मैसेज प्रोसेसर, सर्टिफ़िकेट की पुष्टि करता है. साथ ही, मैसेज #8 में बैकएंड सर्वर के ServerHello मैसेज को स्वीकार करता है.
  5. मैसेज प्रोसेसर, मैसेज #9 में बैकएंड सर्वर को अपना सर्टिफ़िकेट भेजता है.
  6. बैकएंड सर्वर, मैसेज #11 में मैसेज प्रोसेसर का सर्टिफ़िकेट मिलने की सूचना देता है.

  7. हालांकि, यह तुरंत मैसेज प्रोसेसर (मैसेज #12) को गंभीर चेतावनी: खराब सर्टिफ़िकेट भेजता है. इससे पता चलता है कि मैसेज प्रोसेसर से भेजा गया सर्टिफ़िकेट खराब था. इसलिए, बैकएंड सर्वर पर सर्टिफ़िकेट की पुष्टि नहीं हो सकी. इस वजह से, एसएसएल हैंडशेक नहीं हो सका और कनेक्शन बंद हो जाएगा.


    alt_text

  8. आइए, अब मैसेज प्रोसेसर से भेजे गए सर्टिफ़िकेट के कॉन्टेंट की जांच करने के लिए, मैसेज #9 पर नज़र डालते हैं:


    alt_text

  9. जैसा कि आपने देखा, बैकएंड सर्वर को क्लाइंट से कोई सर्टिफ़िकेट नहीं मिला (सर्टिफ़िकेट की लंबाई: 0). इसलिए, बैकएंड सर्वर घातक चेतावनी: खराब सर्टिफ़िकेट भेजता है.
  10. आम तौर पर, ऐसा तब होता है, जब क्लाइंट यानी मैसेज प्रोसेसर (जावा पर आधारित प्रोसेस):
    1. उसके कीस्टोर में कोई क्लाइंट सर्टिफ़िकेट नहीं है, या;
    2. यह क्लाइंट प्रमाणपत्र भेजने में असमर्थ है. ऐसा तब हो सकता है, जब उसे ऐसा सर्टिफ़िकेट न मिले जिसे बैकएंड सर्वर के मान्य सर्टिफ़िकेट में से किसी एक सर्टिफ़िकेट अथॉरिटी ने जारी किया हो. इसका मतलब है कि अगर क्लाइंट के लीफ़ सर्टिफ़िकेट का सर्टिफ़िकेट देने वाली संस्था (यानी कि चेन का पहला सर्टिफ़िकेट), किसी भी बैकएंड सर्वर पर मान्य सर्टिफ़िकेट अथॉरिटी से मेल नहीं खाती है, तो मैसेज प्रोसेसर इस सर्टिफ़िकेट को नहीं भेजेगा.

आइए, इनमें से हर एक वजह पर अलग से नज़र डालते हैं.

वजह: कोई क्लाइंट सर्टिफ़िकेट नहीं है

संक्रमण की जांच

अगर टारगेट एंडपॉइंट के एसएसएल जानकारी सेक्शन में बताए गए Keystore में या टारगेट एंडपॉइंट में इस्तेमाल किए गए टारगेट सर्वर में कोई सर्टिफ़िकेट मौजूद नहीं है, तो इस गड़बड़ी की वजह यही है.

नीचे दिए गए तरीके का इस्तेमाल करके पता लगाएं कि क्या इसकी वजह यह है:

  1. नीचे दिए गए तरीके अपनाकर, तय करें कि किसी खास एपीआई प्रॉक्सी के लिए, टारगेट एंडपॉइंट या टारगेट सर्वर में कीस्टोर का इस्तेमाल किया जा रहा है या नहीं:
    1. टारगेट एंडपॉइंट या टारगेट सर्वर में, SSLInfo सेक्शन में 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 यूज़र इंटरफ़ेस (यूआई) पर जाएं और एपीआई प्रॉक्सी -> एनवायरमेंट कॉन्फ़िगरेशन चुनें.

      रेफ़रंस टैब चुनें और कीस्टोर रेफ़रंस नाम खोजें. किसी खास कीस्टोर रेफ़रंस के लिए, रेफ़रंस कॉलम में नाम नोट कर लें. यह आपका कीस्टोर का नाम होगा.


      alt_text

    4. ऊपर दिए गए उदाहरण में, आप देख सकते हैं कि myKeystoreRef में "myKeystore" का रेफ़रंस है. इसलिए, कीस्टोर का नाम myKeystore है.
  2. देखें कि इस कीस्टोर में सर्टिफ़िकेट शामिल है या नहीं. इसके लिए, Edge यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल किया जा सकता है या कीस्टोर एपीआई के लिए सर्टिफ़िकेट की सूची का इस्तेमाल किया जा सकता है.
  3. अगर कीस्टोर में सर्टिफ़िकेट शामिल है, तो वजह: सर्टिफ़िकेट देने वाली संस्था से मेल न खाने वाला सर्टिफ़िकेट पर जाएं.
  4. अगर कीस्टोर में कोई सर्टिफ़िकेट नहीं है, तो इसी वजह से मैसेज प्रोसेसर से क्लाइंट सर्टिफ़िकेट नहीं भेजा जाता है.

रिज़ॉल्यूशन

  1. पक्का करें कि मैसेज प्रोसेसर में किसी खास कीस्टोर में, सही और पूरी क्लाइंट सर्टिफ़िकेट चेन अपलोड की गई हो.

वजह: सर्टिफ़िकेट देने वाली संस्था या निकाय मेल नहीं खा रहे हैं

आम तौर पर, जब सर्वर, क्लाइंट से अपना सर्टिफ़िकेट भेजने का अनुरोध करता है, तब यह सर्टिफ़िकेट जारी करने वाले लोगों या सर्टिफ़िकेट देने वाली संस्थाओं के सेट की जानकारी देता है. अगर मैसेज प्रोसेसर के कीस्टोर में लीफ़ सर्टिफ़िकेट जारी करने वाली संस्था/सर्टिफ़िकेट की संस्था, (यानी कि सर्टिफ़िकेट की चेन में पहला सर्टिफ़िकेट) की सर्टिफ़िकेट देने वाली संस्था, बैकएंड सर्वर से स्वीकार किए गए किसी भी सर्टिफ़िकेट अथॉरिटी से मेल नहीं खाती है, तो मैसेज प्रोसेसर (यह Java पर आधारित प्रोसेस है) बैकएंड सर्वर पर इस सर्टिफ़िकेट को नहीं भेजेगा.

इस बात की पुष्टि करने के लिए, नीचे दिया गया तरीका अपनाएं:

  1. कीस्टोर एपीआई के लिए सर्टिफ़िकेट की सूची बनाएं.
  2. ऊपर पहले चरण में मिले हर सर्टिफ़िकेट की जानकारी पाने के लिए, कीस्टोर एपीआई के लिए सर्टिफ़िकेट पाएं का इस्तेमाल करें.
  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: नीचे दिए गए Openएसएसएल कमांड का इस्तेमाल करें:

    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: टीसीपी/आईपी पैकेट में Certificate Request पैकेट की जांच करें. इसमें बैकएंड सर्वर, क्लाइंट को अपना सर्टिफ़िकेट भेजने का अनुरोध करता है:

    ऊपर दिखाए गए टीसीपी/आईपी पैकेट के सैंपल में, Certificate Request पैकेट पर मैसेज #7 है. "खास नाम" सेक्शन देखें. इसमें बैकएंड सर्वर के मान्य सर्टिफ़िकेट अथॉरिटी शामिल हैं.

    alt_text

  5. पुष्टि करें कि चरण #3 में मिली सर्टिफ़िकेट अथॉरिटी, चरण #4 में दी गई बैकएंड सर्वर की ओर से स्वीकार किए गए जारी करने वालों या सर्टिफ़िकेट अथॉरिटी की सूची से मेल खाती है या नहीं. अगर यह मेल नहीं खाता है, तो मैसेज प्रोसेसर, क्लाइंट सर्टिफ़िकेट को बैकएंड सर्वर पर नहीं भेजेगा.

    ऊपर दिए गए उदाहरण में, यह देखा जा सकता है कि मैसेज प्रोसेसर के कीस्टोर में क्लाइंट का लीफ़ सर्टिफ़िकेट जारी करने वाली कंपनी, किसी भी बैकएंड सर्वर के स्वीकार किए गए सर्टिफ़िकेट अथॉरिटी से मेल नहीं खाती. इसलिए, मैसेज प्रोसेसर, बैकएंड सर्वर पर क्लाइंट सर्टिफ़िकेट नहीं भेजता. इसकी वजह से, एसएसएल हैंडशेक काम नहीं करता और बैकएंड सर्वर "Fatal alert: bad_certificate" मैसेज भेजता है.

रिज़ॉल्यूशन

  1. पक्का करें कि जारी करने वाली कंपनी/सर्टिफ़िकेट देने वाली संस्था से मिला सर्टिफ़िकेट, उस सर्टिफ़िकेट को बैकएंड सर्वर के Truststore में सेव किया गया हो जो क्लाइंट के लीफ़ सर्टिफ़िकेट को जारी करने वाले/सर्टिफ़िकेट देने वाली संस्था या क्लाइंट के लीफ़ सर्टिफ़िकेट (चेन का पहला सर्टिफ़िकेट) से मेल खाता है.
  2. इस प्लेबुक में दिए गए उदाहरण में, समस्या को ठीक करने के लिए, जारी करने वाले के साथ मिले सर्टिफ़िकेट "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" को बैकएंड सर्वर के Truststore में जोड़ा गया.

अगर समस्या अब भी बनी रहती है, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

डाइग्नोस्टिक की जानकारी ज़रूर इकट्ठा करें

अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो कृपया गड़बड़ी से जुड़ी यह जानकारी इकट्ठा करें. Apigee Edge की सहायता टीम से संपर्क करें और उन्हें शेयर करें:

  1. अगर आप Public Cloud का इस्तेमाल करते हैं, तो यह जानकारी दें:
    1. संगठन का नाम
    2. एनवायरमेंट का नाम
    3. एपीआई प्रॉक्सी का नाम
    4. गड़बड़ी को फिर से सामने लाने के लिए कर्ल कमांड पूरा करें
    5. ट्रेस फ़ाइल की गड़बड़ी दिखा रही है
    6. बैकएंड सर्वर पर कैप्चर किए गए टीसीपी/आईपी पैकेट
  2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
    1. पूरा गड़बड़ी का मैसेज देखा गया
    2. एपीआई प्रॉक्सी बंडल
    3. ट्रेस फ़ाइल की गड़बड़ी दिखा रही है
    4. मैसेज प्रोसेसर के लॉग /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. बैकएंड सर्वर या मैसेज प्रोसेसर पर कैप्चर किए गए टीसीपी/आईपी पैकेट.
    6. कीस्टोर एपीआई के लिए सर्टिफ़िकेट पाएं का आउटपुट.
  3. इस प्लेबुक में मौजूद उन सेक्शन के बारे में जानकारी जिन्हें आपने आज़माया है. साथ ही, ऐसी अन्य अहम जानकारी जिससे हमें इस समस्या को तेज़ी से हल करने में मदद मिलेगी.