400 गलत अनुरोध - एसएसएल सर्टिफ़िकेट से जुड़ी गड़बड़ी

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

पर क्लिक करें.

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

क्लाइंट ऐप्लिकेशन को "एसएसएल सर्टिफ़िकेट से जुड़ी गड़बड़ी" मैसेज के साथ एचटीटीपी 400 - खराब अनुरोध जवाब मिलता है. आम तौर पर, यह गड़बड़ी Edge Router भेजता है. ऐसा तब होता है, जब Apigee Edge से आने वाले कनेक्शन के लिए, दोनों तरफ़ से TLS सेटअप चालू किया गया हो.

गड़बड़ी का मैसेज

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

HTTP/1.1 400 Bad Request

इसके बाद, नीचे दिया गया एचटीएमएल गड़बड़ी वाला पेज दिखेगा:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

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

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

Cause ब्यौरा समस्या हल करने के निर्देश
क्लाइंट सर्टिफ़िकेट की समयसीमा खत्म हो गई है क्लाइंट ने जो सर्टिफ़िकेट भेजा है उसकी समयसीमा खत्म हो गई है. Edge Private और Public Cloud के उपयोगकर्ता
क्लाइंट ने गलत सर्टिफ़िकेट भेजा है यह गड़बड़ी तब होती है, जब क्लाइंट ऐप्लिकेशन से भेजा गया सर्टिफ़िकेट, Edge के राउटर के ट्रस्टस्टोर में सेव किए गए सर्टिफ़िकेट से मेल नहीं खाता. Edge Private और Public Cloud के उपयोगकर्ता
ट्रस्टस्टोर में क्लाइंट का रूट सर्टिफ़िकेट मौजूद नहीं है यह गड़बड़ी तब होती है, जब क्लाइंट के सीए से साइन किया गया रूट सर्टिफ़िकेट, Edge के राउटर के ट्रस्टस्टोर में मौजूद नहीं होता. Edge Private और Public Cloud के उपयोगकर्ता
क्लाइंट सर्टिफ़िकेट, Edge Router में लोड नहीं किए गए हैं यह गड़बड़ी तब दिखती है, जब ट्रस्टस्टोर में अपलोड किए गए क्लाइंट सर्टिफ़िकेट, राउटर पर लोड नहीं होते हैं. Edge Private Cloud के उपयोगकर्ता

वजह: क्लाइंट सर्टिफ़िकेट की समयसीमा खत्म हो गई है

यह समस्या आम तौर पर 2-वे टीएलएस के लिए तब होती है, जब क्लाइंट की ओर से भेजा गया सर्टिफ़िकेट खत्म हो जाता है. दोतरफ़ा टीएलएस में, क्लाइंट और सर्वर, दोनों हैंडशेक पूरा करने के लिए अपने सार्वजनिक सर्टिफ़िकेट का आदान-प्रदान करते हैं. क्लाइंट, सर्वर सर्टिफ़िकेट की पुष्टि करता है और सर्वर, क्लाइंट सर्टिफ़िकेट की पुष्टि करता है.

Edge में, दोनों तरफ़ से टीएलएस की सुविधा को वर्चुअल होस्ट पर लागू किया जाता है. यहां सर्वर सर्टिफ़िकेट को कीस्टोर में जोड़ा जाता है और क्लाइंट सर्टिफ़िकेट को ट्रस्टस्टोर में जोड़ा जाता है.

अगर टीएलएस हैंडशेक के दौरान यह पता चलता है कि क्लाइंट सर्टिफ़िकेट की समयसीमा खत्म हो गई है, तो सर्वर, "एसएसएल सर्टिफ़िकेट से जुड़ी गड़बड़ी" मैसेज के साथ 400 - खराब अनुरोध भेजेगा.

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

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

    आम तौर पर, दोनों तरफ़ से टीएलएस कम्यूनिकेशन के लिए वर्चुअल होस्ट ऐसा दिखता है:

    <VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

  2. वर्चुअल होस्ट में इस्तेमाल किए गए Truststore के रेफ़रंस का पता लगाएं. ऊपर दिए गए उदाहरण में, Truststore के रेफ़रंस का नाम myTruststoreRef है.

  3. ट्रस्टस्टोर के रेफ़रंस से पॉइंट किए गए ट्रस्टस्टोर का पता लगाएं.
    1. Edge यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट > रेफ़रंस पर जाएं और Truststore के रेफ़रंस का नाम खोजें.

    2. किसी खास Truststore रेफ़रंस के लिए, रेफ़रंस कॉलम में दिया गया नाम नोट करें. यह आपके Truststore का नाम होगा.

      Edge यूज़र इंटरफ़ेस (यूआई) की इमेज, जिसमें रेफ़रंस की सूची दिखाई गई है
      पहली इमेज

      ऊपर दिए गए उदाहरण में, ध्यान दें कि myTruststoreRef में myTruststore का रेफ़रंस है. इसलिए, Truststore का नाम myTruststore है.

  4. Edge यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट > टीएलएस कीस्टोर में जाकर, टीएलएस कीस्टोर पर जाएं. इसके बाद, तीसरे चरण में मिला ट्रस्टस्टोर ढूंढें.

  5. नीचे दिए गए तरीके से, खास ट्रस्टस्टोर (ऊपर तीसरे चरण में तय किया गया) में जाकर सर्टिफ़िकेट चुनें:

    दूसरी इमेज

    ऊपर दिए गए उदाहरण में, client-cert-markw उपनाम वाले सर्टिफ़िकेट से पता चलता है कि इसकी समयसीमा खत्म हो गई है.

  6. देखें कि आपके ट्रस्टस्टोर के सर्टिफ़िकेट एलियास के लिए, सर्टिफ़िकेट की समयसीमा खत्म तो नहीं हो गई है.
  7. अगर सर्टिफ़िकेट की समयसीमा खत्म नहीं हुई है, तो अन्य वजहों से होने वाली समस्याओं को हल करने के सामान्य तरीके पर जाएं.

रिज़ॉल्यूशन

नया सर्टिफ़िकेट पाएं और उसे अपलोड करें:

  1. एक नया ट्रस्टस्टोर बनाएं. उदाहरण के लिए, myNewTruststore.
  2. नए बनाए गए ट्रस्टस्टोर में नया सर्टिफ़िकेट अपलोड करें.

  3. रेफ़रंस में बदलाव करना में दिए गए चरणों का इस्तेमाल करके, किसी खास वर्चुअल होस्ट में इस्तेमाल किए गए ट्रस्टस्टोर रेफ़रंस में बदलाव करें, ताकि वह नए ट्रस्टस्टोर की ओर पॉइंट करे.

    ऊपर दिए गए उदाहरण में, myTruststoreRef को myNewTruststore पर ले जाएं.

अन्य वजहों से जुड़ी गड़बड़ियों का पता लगाने के लिए सामान्य तरीके

  1. इस समस्या की जांच करने के लिए, आपको tcpdump टूल का इस्तेमाल करके टीसीपी/आईपी पैकेट कैप्चर करने होंगे.
    1. अगर आप Private Cloud के उपयोगकर्ता हैं, तो क्लाइंट ऐप्लिकेशन या राऊटर पर टीसीपी/आईपी पैकेट कैप्चर किए जा सकते हैं.
    2. अगर आप पब्लिक क्लाउड का इस्तेमाल कर रहे हैं, तो क्लाइंट ऐप्लिकेशन पर टीसीपी/आईपी पैकेट कैप्चर करें.

    3. टीसीपी/आईपी पैकेट को कैप्चर करने के लिए, यहां दी गई tcpdump कमांड का इस्तेमाल करें:

      tcpdump -i any -s 0 host <IP address> -w <File name>

      ध्यान दें: अगर आपको राउटर पर टीसीपी/आईपी पैकेट लेने हैं, तो tcpdump कमांड में क्लाइंट ऐप्लिकेशन के सार्वजनिक आईपी पते का इस्तेमाल करें.

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

      इस टूल और इस कमांड के अन्य वैरिएंट के बारे में ज़्यादा जानकारी के लिए, tcpdump देखें.

  2. Wireshark टूल या ऐसे ही किसी टूल का इस्तेमाल करके इकट्ठा किए गए टीसीपी/आईपी पैकेट का विश्लेषण करें.

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

  1. नीचे दी गई इमेज में tcpdump के पैकेट #30 से पता चलता है कि क्लाइंट ऐप्लिकेशन (सोर्स) ने राउटर (डेस्टिनेशन) को"क्लाइंट हैलो" मैसेज भेजा है.
  2. पैकेट #34 से पता चलता है कि राउटर, क्लाइंट ऐप्लिकेशन से मिले क्लाइंट हैलो मैसेज को स्वीकार करता है.
  3. राउटर, पैकेट #35 में "सर्वर हैलो" भेजता है. इसके बाद, वह अपना सर्टिफ़िकेट भेजता है. साथ ही, क्लाइंट ऐप्लिकेशन से पैकेट #38 में अपना सर्टिफ़िकेट भेजने का अनुरोध करता है.
  4. पैकेट #38 में, राउटर "सर्टिफ़िकेट का अनुरोध" पैकेट भेजता है. इसमें "डिस्टिंग्विश्ड नेम" सेक्शन देखें. इसमें क्लाइंट सर्टिफ़िकेट, उसकी चेन, और सर्टिफ़िकेट देने वाली उन संस्थाओं के बारे में जानकारी होती है जिन्हें राउटर (सर्वर) स्वीकार करता है.
    5. तीसरी इमेज

  5. क्लाइंट ऐप्लिकेशन, पैकेट # 41 में अपना सर्टिफ़िकेट भेजता है. पैकेट # 41 में सर्टिफ़िकेट की पुष्टि करें सेक्शन देखें और पता लगाएं कि क्लाइंट ऐप्लिकेशन ने कौन-सा सर्टिफ़िकेट भेजा है.

    चौथी इमेज
  6. पुष्टि करें कि क्लाइंट ऐप्लिकेशन (पैकेट #41) से भेजे गए सर्टिफ़िकेट और उसकी चेन का विषय और जारी करने वाला व्यक्ति, राउटर (पैकेट #38) से स्वीकार किए गए सर्टिफ़िकेट और उसकी चेन से मेल खाता हो. अगर कोई जानकारी मेल नहीं खाती है, तो इस गड़बड़ी की वजह यही है. इसलिए, राउटर (सर्वर) क्लाइंट ऐप्लिकेशन को एन्क्रिप्ट (सुरक्षित) की गई सूचना (पैकेट #57) भेजता है. इसके बाद, FIN, ACK (पैकेट 58) भेजता है. आखिर में, कनेक्शन बंद हो जाता है.
  7. सर्टिफ़िकेट और उसकी चेन के मेल न खाने की वजहें, यहां दी गई हैं.

वजह: क्लाइंट ने गलत सर्टिफ़िकेट भेजा है

आम तौर पर, ऐसा तब होता है, जब क्लाइंट ऐप्लिकेशन से भेजे गए सर्टिफ़िकेट और/या उसकी चेन का विषय/जारीकर्ता, राउटर (सर्वर) के ट्रस्टस्टोर में सेव किए गए सर्टिफ़िकेट और/या उसकी चेन से मेल नहीं खाता.

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

  1. Edge UI में साइन इन करें और उस वर्चुअल होस्ट का कॉन्फ़िगरेशन देखें जिसके लिए एपीआई अनुरोध किया जा रहा है. इसके लिए, एडमिन > वर्चुअल होस्ट पर जाएं. इसके अलावा, Get virtual host API मैनेजमेंट एपीआई का इस्तेमाल करके, उस वर्चुअल होस्ट की परिभाषा पाएं.

    आम तौर पर, दोनों तरफ़ से टीएलएस कम्यूनिकेशन के लिए वर्चुअल होस्ट ऐसा दिखता है:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. वर्चुअल होस्ट में इस्तेमाल किए गए Truststore के रेफ़रंस का पता लगाएं.

    ऊपर दिए गए उदाहरण में, Truststore के रेफ़रंस का नाम myCompanyTruststoreRef है.

  3. ट्रस्टस्टोर रेफ़रंस से पॉइंट किए गए ट्रस्टस्टोर का पता लगाएं.
    1. Edge के यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट के रेफ़रंस पर जाएं. इसके बाद, Truststore के रेफ़रंस का नाम खोजें.

    2. किसी खास Truststore रेफ़रंस के लिए, रेफ़रंस कॉलम में दिया गया नाम नोट करें. यह आपके Truststore का नाम होगा.

      Edge के यूज़र इंटरफ़ेस (यूआई) में, ट्रस्टस्टोर का रेफ़रंस दिखाया गया है.
      पांचवीं इमेज

      ऊपर दिए गए उदाहरण में, ध्यान दें कि myCompanyTruststoreRef में myCompanyTruststore का रेफ़रंस है. इसलिए, Truststore का नाम myCompanyTruststore है.

  4. ट्रस्टस्टोर में सेव किए गए सर्टिफ़िकेट (पिछले चरण में तय किया गया) पाने के लिए, इन एपीआई का इस्तेमाल करें:

    1. कीस्टोर या ट्रस्टस्टोर एपीआई के लिए सर्टिफ़िकेट की सूची बनाएं.

      यह एपीआई, किसी खास ट्रस्टस्टोर में मौजूद सभी सर्टिफ़िकेट की सूची दिखाता है.

    2. कीस्टोर या ट्रस्टस्टोर एपीआई से सर्टिफ़िकेट की जानकारी पाएं.

      यह एपीआई, किसी खास ट्रस्टस्टोर में मौजूद किसी खास सर्टिफ़िकेट के बारे में जानकारी दिखाता है.

  5. जांच करें कि myCompanyTruststore में सेव किए गए हर सर्टिफ़िकेट और उसकी चेन का जारी करने वाला और विषय, ऊपर दिए गए टीसीपी/आईपी पैकेट (पैकेट #38 देखें) में मौजूद सर्टिफ़िकेट और उसकी चेन के जारी करने वाले और विषय से मेल खाता हो. अगर कोई अंतर दिखता है, तो इसका मतलब है कि ट्रस्टस्टोर में अपलोड किए गए सर्टिफ़िकेट, Edge Router में लोड नहीं हो रहे हैं. वजह: Edge Router में क्लाइंट सर्टिफ़िकेट लोड नहीं किए गए हैं पर जाएं.
  6. अगर चरण #5 में कोई अंतर नहीं मिला है, तो इसका मतलब है कि क्लाइंट ऐप्लिकेशन ने सही सर्टिफ़िकेट और उसकी चेन नहीं भेजी है.

रिज़ॉल्यूशन

पक्का करें कि क्लाइंट ऐप्लिकेशन, Edge को सही सर्टिफ़िकेट और उसकी चेन भेज रहा हो.

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

यह गड़बड़ी तब होती है, जब क्लाइंट के सीए से साइन किया गया रूट सर्टिफ़िकेट, Edge के राउटर के ट्रस्टस्टोर में मौजूद नहीं होता.

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

  1. Edge के यूज़र इंटरफ़ेस (यूआई) में साइन इन करें और उस वर्चुअल होस्ट का कॉन्फ़िगरेशन देखें जिसके लिए एपीआई अनुरोध किया जा रहा है (एडमिन > वर्चुअल होस्ट > virtual_host). इसके अलावा, Get virtual host API का इस्तेमाल करके, उस वर्चुअल होस्ट की परिभाषा पाएं.

    आम तौर पर, दो-तरफ़ा टीएलएस कम्यूनिकेशन के लिए वर्चुअल होस्ट ऐसा दिखता है:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. वर्चुअल होस्ट में इस्तेमाल किए गए ट्रस्टस्टोर रेफ़रंस का पता लगाएं. पिछले उदाहरण में, ट्रस्टस्टोर के रेफ़रंस का नाम myCompanyTruststoreRef है.
  3. यह पता लगाएं कि ट्रस्टस्टोर रेफ़रंस के ज़रिए कौनसा ट्रस्टस्टोर इस्तेमाल किया जा रहा है.
  4. Edge यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट > रेफ़रंस पर जाएं और ट्रस्टस्टोर के रेफ़रंस का नाम खोजें.

  5. किसी खास ट्रस्टस्टोर रेफ़रंस के लिए ट्रस्टस्टोर का नाम, रेफ़रंस कॉलम में होता है.

    छठी इमेज

    इस उदाहरण में ध्यान दें कि myCompanyTruststoreRef में, रेफ़रंस कॉलम में myCompanyTruststore है. इसलिए, truststore का नाम myCompanyTruststore है.

  6. ट्रस्टस्टोर में सेव किए गए सर्टिफ़िकेट (पिछले चरण में तय किया गया) पाने के लिए, इन एपीआई का इस्तेमाल करें:
    1. किसी कीस्टोर या ट्रस्टस्टोर एपीआई के लिए सर्टिफ़िकेट की सूची बनाएं. यह एपीआई, ट्रस्टस्टोर में मौजूद सभी सर्टिफ़िकेट की सूची दिखाता है.
    2. किसी कीस्टोर या ट्रस्टस्टोर एपीआई से सर्टिफ़िकेट की जानकारी पाएं. यह एपीआई, ट्रस्टस्टोर में मौजूद किसी सर्टिफ़िकेट के बारे में जानकारी दिखाता है.

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

    हालांकि, अगर क्लाइंट की पूरी सर्टिफ़िकेट चेन, जिसमें रूट सर्टिफ़िकेट भी शामिल है, ट्रस्टस्टोर में मौजूद है, तो इसका मतलब है कि ट्रस्टस्टोर में अपलोड किए गए सर्टिफ़िकेट, Edge Router में लोड नहीं किए गए हैं. अगर ऐसा है, तो वजह: Edge Router में क्लाइंट सर्टिफ़िकेट लोड नहीं किए गए हैं देखें.

रिज़ॉल्यूशन

पक्का करें कि Apigee Edge राउटर के ट्रस्टस्टोर में, क्लाइंट का सही सर्टिफ़िकेट मौजूद हो. इसमें रूट सर्टिफ़िकेट भी शामिल है.

वजह: Edge Router में क्लाइंट सर्टिफ़िकेट लोड नहीं किए गए हैं

  1. अगर आप Public Cloud के उपयोगकर्ता हैं, तो Apigee Edge की सहायता टीम से संपर्क करें.
  2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो हर राउटर पर यहां दिया गया तरीका अपनाएं:
    1. देखें कि क्या फ़ाइल /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem किसी खास वर्चुअल होस्ट के लिए मौजूद है. अगर फ़ाइल मौजूद नहीं है, तो नीचे दिए गए समस्या हल करना सेक्शन पर जाएं.
    2. अगर फ़ाइल मौजूद है, तो Edge Router पर उपलब्ध सर्टिफ़िकेट की जानकारी पाने के लिए, नीचे दिए गए openssl कमांड का इस्तेमाल करें: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. सर्टिफ़िकेट जारी करने वाले व्यक्ति या कंपनी, विषय, और उसके खत्म होने की तारीख की जांच करें. अगर इनमें से कोई भी वैल्यू, Edge UI में Truststore में देखी गई वैल्यू या मैनेजमेंट एपीआई का इस्तेमाल करके देखी गई वैल्यू से मेल नहीं खाती है, तो यह गड़बड़ी की वजह है.
    4. ऐसा हो सकता है कि राउटर ने अपलोड किए गए सर्टिफ़िकेट को फिर से लोड न किया हो.

रिज़ॉल्यूशन

यह पक्का करने के लिए कि सबसे नए सर्टिफ़िकेट लोड हो गए हैं, राउटर को रीस्टार्ट करें. इसके लिए, यह तरीका अपनाएं:

apigee-service edge-router restart

एपीआई को फिर से चलाएं और नतीजे देखें. अगर समस्या बनी रहती है, तो डाइग्नोस्टिक की जानकारी इकट्ठा करें पर जाएं.

गड़बड़ी की जानकारी इकट्ठा करना

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

  1. अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो यह जानकारी दें:
    1. संगठन का नाम
    2. एनवायरमेंट का नाम
    3. एपीआई प्रॉक्सी का नाम
    4. वर्चुअल होस्ट का नाम
    5. होस्ट का दूसरा नाम
    6. गड़बड़ी को फिर से बनाने के लिए, कर्ल कमांड को पूरा करें
    7. क्लाइंट ऐप्लिकेशन पर कैप्चर किए गए टीसीपी/आईपी पैकेट
  2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
    1. Get virtual host API का इस्तेमाल करके, वर्चुअल होस्ट का नाम और उसकी परिभाषा
    2. होस्ट का दूसरा नाम
    3. गड़बड़ी का पूरा मैसेज मिला
    4. क्लाइंट ऐप्लिकेशन या राउटर पर कैप्चर किए गए टीसीपी/आईपी पैकेट.
    5. keystore API से प्रमाणपत्रों की सूची बनाएं API का आउटपुट. साथ ही, Get cert details API का इस्तेमाल करके हासिल किए गए हर प्रमाणपत्र की जानकारी.
  3. इस प्लेबुक के किन सेक्शन में दिए गए सुझावों को आपने आज़माया है और इस समस्या को तेज़ी से हल करने में मदद करने वाली कोई अन्य अहम जानकारी.