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

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

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

क्लाइंट ऐप्लिकेशन को "एसएसएल सर्टिफ़िकेट से जुड़ी गड़बड़ी" मैसेज के साथ एचटीटीपी 400 - खराब अनुरोध वाला रिस्पॉन्स मिलता है. यह गड़बड़ी आम तौर पर Edge राऊटर से भेजा जाता है. यह 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 Description समस्या हल करने वाले निर्देश इन पर लागू होते हैं
क्लाइंट सर्टिफ़िकेट की समयसीमा खत्म होना क्लाइंट के भेजे गए सर्टिफ़िकेट की समयसीमा खत्म हो गई है. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
क्लाइंट ने गलत सर्टिफ़िकेट भेजा है अगर क्लाइंट ऐप्लिकेशन से भेजा गया सर्टिफ़िकेट, Edge के राऊटर के ट्रस्टस्टोर में सेव किए गए सर्टिफ़िकेट से मेल नहीं खाता है, तो यह गड़बड़ी दिखती है. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
Truststore में क्लाइंट रूट सर्टिफ़िकेट मौजूद नहीं है यह गड़बड़ी तब दिखती है, जब Edge के राऊटर के ट्रस्टस्टोर में क्लाइंट के CA से साइन किया गया रूट सर्टिफ़िकेट मौजूद न हो. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
Edge राऊटर में क्लाइंट सर्टिफ़िकेट लोड नहीं हैं यह गड़बड़ी तब होती है, जब ट्रस्टस्टोर पर अपलोड किए गए क्लाइंट सर्टिफ़िकेट, राऊटर पर लोड नहीं होते. Edge Private Cloud के उपयोगकर्ता

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

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

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

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

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

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

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

    <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. Truststore रेफ़रंस के ज़रिए बताया गया Truststore तय करें.
    1. Edge यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट > रेफ़रंस पर जाएं और Truststore के रेफ़रंस का नाम खोजें.

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

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

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

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

  5. नीचे दिखाए गए तरीके से खास Truststore (ऊपर दिए गए चरण #3 में तय किया गया) के तहत प्रमाणपत्र चुनें:

    दूसरी इमेज

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

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

रिज़ॉल्यूशन

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

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

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

    ऊपर दिए गए उदाहरण में, myTruststoreRef से myNewTruststore रेफ़रंस को पॉइंट करें.

अन्य वजहों का पता लगाने के सामान्य तरीके

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        <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. Truststore रेफ़रंस के ज़रिए बताए गए Truststore को तय करें.
    1. Edge यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट रेफ़रंस पर जाएं और Truststore के रेफ़रंस का नाम खोजें.

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

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

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

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

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

      यह एपीआई, किसी खास Truststore के सभी सर्टिफ़िकेट की सूची बनाता है.

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

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

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

रिज़ॉल्यूशन

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

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

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

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

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

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

        <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 रेफ़रंस का नाम myCompanyTruststoreRef है.
  3. यह पता लगाएं कि Truststore रेफ़रंस के लिए, असल में कौनसा ट्रस्टस्टोर इस्तेमाल किया जा रहा है.
  4. Edge के यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट > पहचान पर जाएं और Truststore के रेफ़रंस का नाम खोजें.

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

    छठी इमेज

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

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

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

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

रिज़ॉल्यूशन

पक्का करें कि रूट सर्टिफ़िकेट के साथ-साथ सही क्लाइंट का सर्टिफ़िकेट, Apigee Edge राऊटर के ट्रस्टस्टोर में उपलब्ध है.

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

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

रिज़ॉल्यूशन

नीचे दिए गए चरण का इस्तेमाल करके नए सर्टिफ़िकेट लोड किए गए हैं, यह पक्का करने के लिए राऊटर को रीस्टार्ट करें:

apigee-service edge-router restart

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

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

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

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