TLS/एसएसएल हैंडशेक से जुड़ी गड़बड़ियां

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

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

TLS/SSL हैंडशेक गड़बड़ी तब होती है, जब क्लाइंट और सर्वर TLS/एसएसएल प्रोटोकॉल. Apigee Edge में यह गड़बड़ी होने पर, क्लाइंट को ऐप्लिकेशन को सेवा उपलब्ध नहीं है मैसेज के साथ एचटीटीपी स्थिति 503 मिलती है. आपने लोगों तक पहुंचाया मुफ़्त में अगर TLS/एसएसएल हैंडशेक से जुड़ी गड़बड़ी होती है, तो किसी एपीआई कॉल के बाद यह गड़बड़ी दिखती है.

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

HTTP/1.1 503 Service Unavailable

TLS/SSL हैंडशेक विफल होने पर भी आपको यह गड़बड़ी संदेश दिखाई दे सकता है:

Received fatal alert: handshake_failure

संभावित कारण

TLS (ट्रांसपोर्ट लेयर सिक्योरिटी, जिसका पिछला नाम एसएसएल है), किसी वेब सर्वर और वेब क्लाइंट, जैसे कि ब्राउज़र या ऐप्लिकेशन के बीच एन्क्रिप्ट (सुरक्षित) किया गया लिंक बनाना. हैंडशेक ऐसी प्रोसेस है जिसकी मदद से TLS/एसएसएल क्लाइंट और सर्वर, सीक्रेट का सेट बना पाता है जिनसे वे बातचीत कर सकें. इस प्रोसेस के दौरान, क्लाइंट और सर्वर:

1. इस्तेमाल करने के लिए प्रोटोकॉल के वर्शन पर सहमति दें.
2. इस्तेमाल के लिए क्रिप्टोग्राफ़िक एल्गोरिदम चुनें.
3. डिजिटल सर्टिफ़िकेट की अदला-बदली करके और उनकी पुष्टि करके एक-दूसरे की पुष्टि करें.

अगर TLS/SSL हैंडशेक सफल होता है, तो TLS/SSL क्लाइंट और सर्वर प्रत्येक को डेटा ट्रांसफ़र करते हैं दूसरे सुरक्षित तरीके से काम करें. अन्यथा, अगर TLS/SSL हैंडशेक विफल होता है, तो कनेक्शन खत्म हो जाता है और क्लाइंट 503 Service Unavailable गड़बड़ी मिलती है.

TLS/एसएसएल हैंडशेक के काम न करने की संभावित वजहें ये हैं:

प्रोटोकॉल मैच नहीं हो रहा

TLS/एसएसएल हैंडशेक तब काम नहीं करता, जब क्लाइंट का इस्तेमाल किया गया प्रोटोकॉल सर्वर या तो इनकमिंग (नॉर्थबाउंड) या आउटगोइंग (आउटबाउंड) कनेक्शन पर. इन्हें भी देखें उत्तर की ओर और दक्षिण की ओर के कनेक्शन को समझना.

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

1. पता लगाएं कि गड़बड़ी नॉर्थबाउंड पर हुई है या दक्षिणबाउंड कनेक्शन. इस बारे में अतिरिक्त दिशा-निर्देश पाने के लिए दृढ़ संकल्प, देखें समस्या की वजह का पता लगाना.
2. यह चलाकर देखेंः tcpdump यूटिलिटी इकट्ठा करें:
   • अगर आप निजी Cloud उपयोगकर्ता हैं, तो आपके पास tcpdump डेटा का उपयोग कर सकते हैं. क्लाइंट ही क्लाइंट ऐप्लिकेशन हो सकता है (इनकमिंग, या नॉर्थबाउंड कनेक्शन) या मैसेज प्रोसेसर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए). सर्वर एक Edge राऊटर हो सकता है (इसके लिए इनकमिंग या नॉर्थबाउंड कनेक्शन) या बैकएंड सर्वर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए) के लिए.
   • अगर आप सार्वजनिक क्लाउड के उपयोगकर्ता हैं, तो आपके पास tcpdump इकट्ठा करने का विकल्प है डेटा सिर्फ़ क्लाइंट ऐप्लिकेशन (इनकमिंग या नॉर्थबाउंड कनेक्शन के लिए) या बैकएंड सर्वर पर मौजूद होगा (आउटगोइंग या साउथबाउंड कनेक्शन के लिए), क्योंकि आपके पास Edge राऊटर या मैसेज प्रोसेसर का ऐक्सेस नहीं होता है.

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

   देखें tcpdump डेटा के लिए, tcpdump के इस्तेमाल के बारे में ज़्यादा जानें आदेश.
3. Wireshark टूल का इस्तेमाल करके, tcpdump के डेटा का विश्लेषण करना या मिलते-जुलते टूल का इस्तेमाल किया जा सकता है.
4. यहाँ इसका सैंपल विश्लेषण दिया गया है: Wireshark का इस्तेमाल करके tcpdump:
   • इस उदाहरण में, संदेश प्रोसेसर और बैकएंड सर्वर (आउटगोइंग या साउथबाउंड कनेक्शन).
   • नीचे दिए गए tcpdump आउटपुट में मैसेज #4 दिखाता है कि मैसेज प्रोसेसर (सोर्स) ने "क्लाइंट को नमस्ते" संदेश भेजने के लिए कहें.
     

     

   • अगर Client Hello मैसेज को चुना जाता है, तो पता चलता है कि मैसेज प्रोसेसर TLSv1.2 प्रोटोकॉल, जैसा कि नीचे दिखाया गया है:

     

   • मैसेज #5 से पता चलता है कि बैकएंड सर्वर ने "क्लाइंट हैलो" को स्वीकार किया है मैसेज इनसे मिला मैसेज प्रोसेसर चुन सकते हैं.
   • बैकएंड सर्वर तुरंत गंभीर सूचना : सूचित करें को बंद करें मैसेज प्रोसेसर (मैसेज #6). इसका मतलब है कि TLS/SSL हैंडशेक विफल हो गया और कनेक्शन बंद हो जाएगा.

   • संदेश #6 में आगे देखने से पता चलता है कि TLS/एसएसएल हैंडशेक की गड़बड़ी का कारण यह है कि बैकएंड सर्वर सिर्फ़ TLSv1.0 प्रोटोकॉल के साथ काम करता है, जैसा कि नीचे दिखाया गया है:

     

   • मैसेज प्रोसेसर और मैसेज प्रोसेसर में इस्तेमाल होने वाले प्रोटोकॉल के बीच कोई अंतर नहीं है बैकएंड सर्वर ने यह मैसेज भेजा: गंभीर चेतावनी का मैसेज: बंद करें सूचना दें.

रिज़ॉल्यूशन

मैसेज प्रोसेसर, Java 8 पर चलता है और डिफ़ॉल्ट रूप से TLSv1.2 प्रोटोकॉल का इस्तेमाल करता है. अगर बैकएंड सर्वर TLSv1.2 प्रोटोकॉल का समर्थन नहीं करता है, फिर आप समाधान के लिए निम्न में से एक चरण अपना सकते हैं इस समस्या के लिए:

1. TLSv1.2 प्रोटोकॉल के साथ काम करने के लिए, अपना बैकएंड सर्वर अपग्रेड करें. हमारा सुझाव है कि तो प्रोटोकॉल TLSv1.2 ज़्यादा सुरक्षित है.
2. अगर किसी वजह से तुरंत अपना बैकएंड सर्वर अपग्रेड नहीं हो पा रहा, तो बातचीत करने के लिए, मैसेज प्रोसेसर को TLSv1.0 प्रोटोकॉल का इस्तेमाल करने के लिए कहें बैकएंड सर्वर पर काम करने के लिए, यह तरीका अपनाएं:
   1. अगर आपने प्रॉक्सी की TargetEndpoint परिभाषा में कोई टारगेट सर्वर तय नहीं किया है, तो TLSv1.0 के लिए Protocol एलिमेंट को दिखाया गया है नीचे दिया गया है:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. अगर आपने किसी टारगेट सर्वर को लक्षित करें, फिर इसका उपयोग करें यह मैनेजमेंट एपीआई है, ताकि प्रोटोकॉल को टारगेट सर्वर कॉन्फ़िगरेशन.

सिफ़र मेल नहीं खाता

अगर क्लाइंट, साइफ़र सुइट एल्गोरिदम का इस्तेमाल नहीं करता है, तो आपको TLS/एसएसएल हैंडशेक की गड़बड़ी दिख सकती है यह सर्वर, Apigee Edge में इनकमिंग (नॉर्थबाउंड) या आउटगोइंग (आउटबाउंड) कनेक्शन पर काम करता है. यह भी देखें उत्तर की ओर और दक्षिण की ओर के कनेक्शन को समझना.

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

1. पता करें कि क्या त्रुटि इस समय हुई नॉर्थबाउंड या साउथबाउंड कनेक्शन. यह तय करने के बारे में ज़्यादा जानकारी के लिए, यहां देखें तय करना समस्या की वजह क्या है.
2. यह चलाकर देखेंः tcpdump यूटिलिटी इकट्ठा करें:
   • अगर आप निजी Cloud उपयोगकर्ता हैं, तो आपके पास tcpdump डेटा का उपयोग कर सकते हैं. क्लाइंट ही क्लाइंट ऐप्लिकेशन हो सकता है (इनकमिंग, या नॉर्थबाउंड कनेक्शन) या मैसेज प्रोसेसर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए). सर्वर एक Edge राऊटर हो सकता है (इसके लिए इनकमिंग या नॉर्थबाउंड कनेक्शन) या बैकएंड सर्वर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए) के लिए.
   • अगर आप सार्वजनिक क्लाउड के उपयोगकर्ता हैं, तो आपके पास tcpdump इकट्ठा करने का विकल्प है डेटा सिर्फ़ क्लाइंट ऐप्लिकेशन (इनकमिंग या नॉर्थबाउंड कनेक्शन के लिए) या बैकएंड सर्वर पर मौजूद होगा (आउटगोइंग या साउथबाउंड कनेक्शन के लिए), क्योंकि आपके पास Edge राऊटर या मैसेज प्रोसेसर का ऐक्सेस नहीं होता है.

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

   देखें tcpdump डेटा की मदद से tcpdump कमांड का इस्तेमाल करने के बारे में ज़्यादा जानें.
3. Wireshark टूल का इस्तेमाल करके, tcpdump के डेटा का विश्लेषण करें किसी ऐसे टूल का इस्तेमाल कर सकते हैं जिसके बारे में आपको जानकारी है.
4. यहां Wireshark का इस्तेमाल करके, tcpdump आउटपुट का विश्लेषण किया गया है:
   • इस उदाहरण में, क्लाइंट ऐप्लिकेशन और Edge राऊटर (नॉर्थबाउंड कनेक्शन). tcpdump आउटपुट, Edge पर इकट्ठा किया गया था राऊटर.

   • नीचे दिए गए tcpdump आउटपुट में मैसेज #4 दिखाता है कि क्लाइंट ऐप्लिकेशन (सोर्स) ने "क्लाइंट को नमस्ते" मैसेज को एज राऊटर (डेस्टिनेशन) पर भेजा जाएगा.

     

   • क्लाइंट हैलो मैसेज चुनने से पता चलता है कि क्लाइंट ऐप्लिकेशन TLSv1.2 प्रोटोकॉल.

     

   • मैसेज #5 दिखाता है कि Edge राऊटर "क्लाइंट को नमस्ते" स्वीकार कर रहा है मैसेज इनसे मिला क्लाइंट ऐप्लिकेशन को इंस्टॉल करने की कोशिश करेंगे.
   • Edge राऊटर तुरंत इस यूआरएल पर नुकसान पहुंचाने वाली चेतावनी : हैंडशेक की गड़बड़ी की सूचना भेजता है तो क्लाइंट ऐप्लिकेशन (मैसेज #6). इसका मतलब है कि TLS/एसएसएल हैंडशेक नहीं हो सका और कनेक्शन बंद हो जाएगा.
   • मैसेज #6 में और जानकारी पाने से यह जानकारी मिलती है:
     • Edge राऊटर TLSv1.2 प्रोटोकॉल के साथ काम करता है. इसका मतलब है कि प्रोटोकॉल एक-दूसरे से मेल खाता है पर सेट करें.

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

       

   • इनमें से किसी समस्या की वजह से गड़बड़ी हो सकती है:
     • क्लाइंट ऐप्लिकेशन, साइफ़र सुइट एल्गोरिदम का इस्तेमाल नहीं कर रहा है जो एज राऊटर.
     • Edge राऊटर SNI-चालू है, लेकिन क्लाइंट ऐप्लिकेशन सर्वर का नाम.
   • tcpdump आउटपुट में मैसेज #4 में ऐसे साइफ़र सुइट एल्गोरिदम की सूची होती है जो क्लाइंट के साथ काम करते हैं नीचे दिखाया गया है, जैसा कि नीचे दिखाया गया है:

     

   • Edge राऊटर के साथ काम करने वाले साइफ़र सुइट एल्गोरिदम की सूची /opt/nginx/conf.d/0-default.conf फ़ाइल. इस उदाहरण में, Edge राऊटर के बारे में बताया गया है सिर्फ़ हाई एन्क्रिप्शन साइफ़र सुइट एल्गोरिदम के साथ काम करता है.
   • क्लाइंट ऐप्लिकेशन, किसी भी हाई एन्क्रिप्शन वाले साइफ़र सुइट एल्गोरिदम का इस्तेमाल नहीं करता. इस अंतर की वजह है TLS/SSL हैंडशेक विफल रहा.
   • Edge राऊटर में SNI की सुविधा चालू है. इसलिए, tcpdump आउटपुट में मैसेज #4 पर नीचे की ओर स्क्रोल करें और पुष्टि करें कि क्लाइंट ऐप्लिकेशन, सर्वर का नाम सही तरीके से भेज रहा है, जैसा कि इसकी इमेज यहां दी गई है:
     
     
     
   • अगर यह नाम मान्य है, तो यह अनुमान लगाया जा सकता है कि TLS/एसएसएल हैंडशेक गड़बड़ी हो सकती है के साथ हुआ, क्योंकि क्लाइंट ऐप्लिकेशन के ज़रिए इस्तेमाल किए जाने वाले साइफ़र सुइट एल्गोरिदम एज राऊटर पर जाएं.

रिज़ॉल्यूशन

आपको यह पक्का करना होगा कि क्लाइंट साइफ़र सुइट एल्गोरिदम का इस्तेमाल करे, जो जो सर्वर पर काम करता हो. ऊपर बताई गई समस्या को हल करने के लिए विश्लेषण सेक्शन, रिपोर्ट को डाउनलोड और इंस्टॉल करने के लिए Java क्रिप्टोग्राफ़ी एक्सटेंशन (जेसीई) पैकेज और इसे Java में शामिल करना को इंस्टॉल किया गया है.

गलत सर्टिफ़िकेट

अगर आपके पास कीस्टोर/ट्रस्टस्टोर में गलत सर्टिफ़िकेट हैं, तो TLS/एसएसएल हैंडशेक की गड़बड़ी हो सकती है. Apigee Edge में, इनकमिंग (नॉर्थबाउंड) या आउटगोइंग (साउथबाउंड) कनेक्शन पर. इन्हें भी देखें उत्तर की ओर और दक्षिण की ओर के कनेक्शन को समझना.

अगर समस्या नॉर्थबाउंड है, तो आपको गड़बड़ी के अलग-अलग मैसेज दिख सकते हैं ज़रूरी बातों पर निर्भर करता है.

नीचे दिए गए सेक्शन में, गड़बड़ी के मैसेज के उदाहरण दिए गए हैं. साथ ही, गड़बड़ी के बारे में पता लगाने और इसे ठीक करने का तरीका भी बताया गया है समस्या.

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

TLS/SSL हैंडशेक विफल होने की वजहों के आधार पर आपको गड़बड़ी के अलग-अलग मैसेज दिख सकते हैं. यहां गड़बड़ी के एक मैसेज का सैंपल दिया गया है. यह एपीआई प्रॉक्सी को कॉल करने पर दिख सकता है:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

संभावित कारण

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

होस्टनेम मैच नहीं हो रहा

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

1. नीचे दिए गए Edge मैनेजमेंट एपीआई कॉल से मिले यूआरएल में इस्तेमाल किए गए होस्टनेम को नोट करें:

   curl -v https://myorg.domain.com/v1/getinfo

   जैसे:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. किसी कीस्टोर में स्टोर किए गए सर्टिफ़िकेट में इस्तेमाल किया हुआ CN पाएं. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए नीचे दिए गए Edge मैनेजमेंट एपीआई का इस्तेमाल करें, ताकि सर्टिफ़िकेट की जानकारी देखी जा सके:
   1. कीस्टोर में सर्टिफ़िकेट का नाम पाएं:
      
      अगर आप निजी Cloud उपयोगकर्ता हैं, तो Management API का इस्तेमाल इस तरह करें:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      अगर आप सार्वजनिक क्लाउड उपयोगकर्ता हैं, तो Management API का इस्तेमाल इस तरह करें:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Edge management API का इस्तेमाल करके, कीस्टोर में सर्टिफ़िकेट की जानकारी पाएं.
      अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
      अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अगर आप निजी Cloud उपयोगकर्ता हैं, तो:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      अगर आप सार्वजनिक Cloud उपयोगकर्ता हैं:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      सर्टिफ़िकेट का सैंपल::

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      प्राथमिक प्रमाणपत्र में विषय के नाम में CN इस रूप में है something.domain.com. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

      एपीआई अनुरोध के यूआरएल में इस्तेमाल किया गया होस्टनेम (ऊपर दिया गया चरण#1 देखें) और विषय प्रमाणपत्र में मौजूद नाम मेल नहीं खाता, तो आपको TLS/SSL हैंडशेक विफल हो जाएगा.

रिज़ॉल्यूशन

यहां दिए गए दो तरीकों में से किसी एक का इस्तेमाल करके, इस समस्या को हल किया जा सकता है:

• अगर आपके पास पहले से कोई सर्टिफ़िकेट नहीं है, तो विषय के सीएन (CN) में वाइल्डकार्ड वाला सर्टिफ़िकेट पाएं और फिर कीस्टोर में नई पूरी सर्टिफ़िकेट चेन अपलोड करें. उदाहरण के लिए:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• अगर आपके पास पहले से कोई विषय CN नहीं है, तो प्रमाणपत्र लें, लेकिन इसका इस्तेमाल करें your-org.विषय के अन्य नाम के तौर पर your-domain. इसके बाद, पूरा नाम अपलोड करें सर्टिफ़िकेट चेन से भी जोड़ा जा सकता है.

रेफ़रंस

कीस्टोर और Truststores

सर्टिफ़िकेट की चेन अधूरी या गलत है

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

1. किसी कीस्टोर में स्टोर किए गए सर्टिफ़िकेट में इस्तेमाल किया हुआ CN पाएं. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए नीचे दिए गए Edge मैनेजमेंट एपीआई का इस्तेमाल करें, ताकि सर्टिफ़िकेट की जानकारी देखी जा सके:
   1. कीस्टोर में सर्टिफ़िकेट का नाम पाएं:
      
      अगर आप निजी Cloud उपयोगकर्ता हैं, तो:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      अगर आप सार्वजनिक Cloud उपयोगकर्ता हैं:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. कीस्टोर में सर्टिफ़िकेट की जानकारी पाएं:
      
      अगर आप निजी Cloud उपयोगकर्ता हैं, तो:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      अगर आप सार्वजनिक Cloud उपयोगकर्ता हैं:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. सर्टिफ़िकेट और उसकी चेन की पुष्टि करें. साथ ही, पुष्टि करें कि यह इन शर्तों का पालन करता है लेख में दिए गए दिशा-निर्देशों के मुताबिक होने चाहिए सर्टिफ़िकेट चेन कैसे काम करती है, ताकि यह पक्का किया जा सके कि यह मान्य और पूरा है सर्टिफ़िकेट चेन. अगर कीस्टोर में सेव की गई सर्टिफ़िकेट चेन या तो अधूरा हो या अमान्य हो, तो आपको TLS/SSL हैंडशेक दिखेगा अपलोड नहीं किया जा सका.
   4. नीचे दी गई ग्राफ़िकी में, अमान्य सर्टिफ़िकेट चेन वाला सैंपल सर्टिफ़िकेट दिखाया गया है, जहां इंटरमीडिएट और रूट सर्टिफ़िकेट मेल नहीं खाते:

   इंटरमीडिएट और रूट सर्टिफ़िकेट का सैंपल, जहां जारी करने वाला और विषय मेल नहीं खाता

   
   

रिज़ॉल्यूशन

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

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. पुष्टि किए गए सर्टिफ़िकेट की चेन को कीस्टोर में अपलोड करें.

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

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

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

1. पता लगाएं कि गड़बड़ी नॉर्थबाउंड पर हुई है या दक्षिणबाउंड कनेक्शन. इस बारे में अतिरिक्त दिशा-निर्देश पाने के लिए दृढ़ संकल्प, देखें समस्या की वजह का पता लगाना.
2. यह चलाकर देखेंः tcpdump यूटिलिटी इकट्ठा करें:
   • अगर आप निजी Cloud उपयोगकर्ता हैं, तो आपके पास tcpdump डेटा का उपयोग कर सकते हैं. क्लाइंट ही क्लाइंट ऐप्लिकेशन हो सकता है (इनकमिंग, या नॉर्थबाउंड कनेक्शन) या मैसेज प्रोसेसर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए). सर्वर एक Edge राऊटर हो सकता है (इसके लिए इनकमिंग या नॉर्थबाउंड कनेक्शन) या बैकएंड सर्वर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए) के लिए.
   • अगर आप सार्वजनिक क्लाउड के उपयोगकर्ता हैं, तो आपके पास tcpdump इकट्ठा करने का विकल्प है डेटा सिर्फ़ क्लाइंट ऐप्लिकेशन (इनकमिंग या नॉर्थबाउंड कनेक्शन के लिए) या बैकएंड सर्वर पर मौजूद होगा (आउटगोइंग या साउथबाउंड कनेक्शन के लिए), क्योंकि आपके पास Edge राऊटर या मैसेज प्रोसेसर का ऐक्सेस नहीं होता है.

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

   देखें tcpdump डेटा की मदद से tcpdump कमांड का इस्तेमाल करने के बारे में ज़्यादा जानें.
3. tcpdump डेटा का विश्लेषण करने के लिए Wireshark या मिलता-जुलता टूल.
4. tcpdump आउटपुट से, उस होस्ट (क्लाइंट या सर्वर) का पता लगाएं जो सर्टिफ़िकेट से जुड़ी जानकारी शामिल होती है.
5. आप tcpdump आउटपुट से दूसरे सिरे से भेजा गया सर्टिफ़िकेट वापस पा सकते हैं, बशर्ते डेटा एन्क्रिप्ट नहीं किया जाता. यह तुलना करना उपयोगी होगा, अगर यह प्रमाणपत्र सर्टिफ़िकेट, Truststore में उपलब्ध है.
6. मैसेज प्रोसेसर और मैसेज प्रोसेसर के बीच एसएसएल कम्यूनिकेशन के लिए, tcpdump सैंपल देखें भी डाउनलोड कर सकता है.

   सर्टिफ़िकेट की पहचान न होने की गड़बड़ी दिखाने वाला tcpdump का नमूना

   
   

   1. मैसेज प्रोसेसर (क्लाइंट) ने "क्लाइंट को नमस्ते" भेजा है बैकएंड सर्वर से कनेक्ट करता है (सर्वर) को मैसेज #59 में डालें.
   2. बैकएंड सर्वर, "सर्वर हेलो" भेजता है मैसेज में मौजूद मैसेज प्रोसेसर पर #61.
   3. ये इस्तेमाल किए जाने वाले प्रोटोकॉल और साइफ़र सुइट एल्गोरिदम की आपसी सहमति से पुष्टि करते हैं.
   4. बैकएंड सर्वर मैसेज #68 में मैसेज प्रोसेसर.
   5. मैसेज प्रोसेसर ने गंभीर चेतावनी भेजी "जानकारी: सर्टिफ़िकेट अज्ञात" मैसेज #70 में.
   6. मैसेज #70 के बारे में ज़्यादा जानकारी पाने के लिए, यहां अन्य जानकारी उपलब्ध नहीं है चेतावनी संदेश की तुलना में नीचे दिखाया गया है:

      
      

   7. बैकएंड से मिले सर्टिफ़िकेट के बारे में जानकारी पाने के लिए, मैसेज #68 देखें सर्वर का इस्तेमाल करें, जैसा कि इस ग्राफ़िक में दिखाया गया है:

      

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

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Truststore में सर्टिफ़िकेट की जानकारी पाएं:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. देखें कि सर्टिफ़िकेट, राऊटर (नॉर्थबाउंड) के ट्रस्टस्टोर में सेव हुआ है या नहीं या मैसेज प्रोसेसर (दक्षिण की सीमा) उस सर्टिफ़िकेट से मेल खाता है जो क्लाइंट ऐप्लिकेशन (नॉर्थबाउंड) या टारगेट सर्वर (साउथबाउंड) का कीस्टोर या जो tcpdump आउटपुट से मिलता है. अगर यह मेल नहीं खाता है, तो TLS/एसएसएल हैंडशेक से जुड़ी गड़बड़ी.
8. अगर क्लाइंट ऐप्लिकेशन (नॉर्थबाउंड) में सर्टिफ़िकेट के बारे में जानकारी नहीं है या लक्ष्य सर्वर (दक्षिणबाउंड) पर कॉल करें, तो इन चरणों का पालन करें:
   1. आपकी वेबसाइट पर सेव किए गए सर्टिफ़िकेट में इस्तेमाल की जाने वाली पूरी सर्टिफ़िकेट चेन पाएं कीस्टोर पर क्लिक करें. (रूटर और टारगेट एंडपॉइंट के लिए वर्चुअल होस्ट कॉन्फ़िगरेशन देखें मैसेज प्रोसेसर का कॉन्फ़िगरेशन.) पाने के लिए आप निम्न API का उपयोग कर सकते हैं सर्टिफ़िकेट की जानकारी:
      1. कीस्टोर से सर्टिफ़िकेट का नाम पाएं:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. कीस्टोर में सर्टिफ़िकेट की जानकारी पाएं:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. देखें कि सर्टिफ़िकेट, राऊटर (नॉर्थबाउंड) के कीस्टोर में सेव हुआ है या नहीं या मैसेज प्रोसेसर (दक्षिण की सीमा), क्लाइंट ऐप्लिकेशन (नॉर्थबाउंड) या टारगेट सर्वर (साउथबाउंड) या वह tcpdump से मिली. अगर यह मेल नहीं खाता है, तो एसएसएल की वजह से ऐसा होता है हैंडशेक विफल हो गया.
9. अगर किसी सर्वर/क्लाइंट के भेजे गए सर्टिफ़िकेट की समयसीमा खत्म हो जाती है, तो जब क्लाइंट/सर्वर सर्टिफ़िकेट को अस्वीकार कर देता है, तो आपको tcpdump:

   सूचना (लेवल: गंभीर, जानकारी: सर्टिफ़िकेट की समयसीमा खत्म हो गई है)

10. पुष्टि करें कि सही होस्ट के कीस्टोर में मौजूद सर्टिफ़िकेट की समयसीमा खत्म हो गई है.

रिज़ॉल्यूशन

ऊपर दिए गए उदाहरण में बताई गई समस्या को हल करने के लिए, मान्य बैकएंड सर्वर मैसेज प्रोसेसर पर ट्रुस्टोर का सर्टिफ़िकेट.

यहां दी गई टेबल में उन चरणों के बारे में बताया गया है जिनकी मदद से समस्या को ठीक किया जा सकता है. ये तरीके, समस्या.

SNI चालू सर्वर

क्लाइंट के सर्वर से संपर्क करने पर, TLS/एसएसएल हैंडशेक की गड़बड़ी हो सकती है नाम इंडिकेशन (SNI) चालू है सर्वर, लेकिन क्लाइंट SNI सक्षम नहीं है. ऐसा या तो उत्तर की सीमा पर या Edge में साउथबाउंड कनेक्शन है.

सबसे पहले, आपको इस्तेमाल किए जा रहे सर्वर के होस्टनेम और पोर्ट नंबर की पहचान करनी होगी. साथ ही, यह देखना होगा कि यह SNI सक्षम है या नहीं.

SNI सक्षम सर्वर की पहचान

1. openssl निर्देश चलाएं और सही सर्वर होस्टनेम (Edge) से कनेक्ट करने की कोशिश करें राऊटर या बैकएंड सर्वर) सर्वर का नाम पास किए बिना, जैसा कि नीचे दिखाया गया है:

   openssl s_client -connect hostname:port

   आपको सर्टिफ़िकेट मिल सकते हैं और कभी-कभी आपको इनमें से किसी गड़बड़ी की वजह से हैंडशेक करने में समस्या हो सकती है Openएसएसएल कमांड की मदद से, जैसा कि नीचे दिखाया गया है:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. openssl निर्देश चलाएं और सही सर्वर होस्टनेम से कनेक्ट करने की कोशिश करें (एज राऊटर या बैकएंड सर्वर) सर्वर का नाम पास करके नीचे देखें:

   openssl s_client -connect hostname:port -servername hostname

3. अगर चरण #1 में हैंडशेक नहीं हो पाता है या चरण #1 में अलग-अलग सर्टिफ़िकेट मिले हैं और चरण #2 है, तो यह बताता है कि बताया गया सर्वर SNI चालू है.

जब आप यह पता लगा लें कि सर्वर SNI सक्षम है, तो आप देखें कि TLS/एसएसएल हैंडशेक की वजह से क्लाइंट, SNI सर्वर पर.

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

1. पता लगाएं कि गड़बड़ी नॉर्थबाउंड पर हुई है या दक्षिणबाउंड कनेक्शन. इस बारे में अतिरिक्त दिशा-निर्देश पाने के लिए दृढ़ संकल्प, देखें समस्या की वजह का पता लगाना.
2. यह चलाकर देखेंः tcpdump यूटिलिटी इकट्ठा करें:
   • अगर आप निजी Cloud उपयोगकर्ता हैं, तो आपके पास tcpdump डेटा का उपयोग कर सकते हैं. क्लाइंट ही क्लाइंट ऐप्लिकेशन हो सकता है (इनकमिंग, या नॉर्थबाउंड कनेक्शन) या मैसेज प्रोसेसर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए). सर्वर एक Edge राऊटर हो सकता है (इसके लिए इनकमिंग या नॉर्थबाउंड कनेक्शन) या बैकएंड सर्वर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए) के लिए.
   • अगर आप सार्वजनिक क्लाउड के उपयोगकर्ता हैं, तो आपके पास tcpdump इकट्ठा करने का विकल्प है डेटा सिर्फ़ क्लाइंट ऐप्लिकेशन (इनकमिंग या नॉर्थबाउंड कनेक्शन के लिए) या बैकएंड सर्वर पर मौजूद होगा (आउटगोइंग या साउथबाउंड कनेक्शन के लिए), क्योंकि आपके पास Edge राऊटर या मैसेज प्रोसेसर का ऐक्सेस नहीं होता है.

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

   यहां जाएं: tcpdump डेटा की मदद से tcpdump कमांड का इस्तेमाल करने के बारे में ज़्यादा जानें.
3. Wireshark याtcpdump मिलता-जुलता टूल.
4. यहां Wireshark का इस्तेमाल करके tcpdump का विश्लेषण किया गया है:
   1. इस उदाहरण में, Edge मैसेज के बीच TLS/एसएसएल हैंडशेक फ़ेल हो गया प्रोसेसर और बैकएंड सर्वर (दक्षिणबाउंड कनेक्शन).
   2. नीचे दिए गए tcpdump आउटपुट में मैसेज #4 दिखाता है कि मैसेज प्रोसेसर (सोर्स) ने "क्लाइंट को नमस्ते" मैसेज को बैकएंड सर्वर (डेस्टिनेशन) पर भेजा जाएगा.

      

   3. "क्लाइंट को नमस्ते" चुनना तो मैसेज दिखाता है कि प्रोसेसर, TLSv1.2 प्रोटोकॉल का इस्तेमाल कर रहा है.

      

   4. मैसेज #4 दिखाता है कि बैकएंड सर्वर "क्लाइंट हैलो" को स्वीकार करता है मैसेज मैसेज प्रोसेसर से मिल रही है.
   5. बैकएंड सर्वर तुरंत एक घातक चेतावनी : हैंडशेक भेजता है मैसेज प्रोसेसर की गड़बड़ी (मैसेज #5). इसका मतलब है TLS/एसएसएल हैंडशेक विफल रहा और कनेक्शन बंद हो जाएगा.
   6. यह जानकारी पाने के लिए, मैसेज #6 की समीक्षा करें
      • बैकएंड सर्वर, TLSv1.2 प्रोटोकॉल के साथ काम करता है. इसका मतलब है कि प्रोटोकॉल मैसेज प्रोसेसर और बैकएंड सर्वर के बीच मैच हुआ.
      • हालांकि, बैकएंड सर्वर अब भी घातक चेतावनी: हैंडशेक भेजता है मैसेज प्रोसेसर में गड़बड़ी, जैसा कि नीचे दी गई इमेज में दिखाया गया है:

        

   7. यह गड़बड़ी, इनमें से किसी एक वजह से हो सकती है:
      • मैसेज प्रोसेसर, साइफ़र सुइट एल्गोरिदम का इस्तेमाल नहीं कर रहा है. ये एल्गोरिदम बैकएंड सर्वर.
      • बैकएंड सर्वर SNI सक्षम है, लेकिन क्लाइंट ऐप्लिकेशन भेज नहीं रहा है सर्वर का नाम.
   8. tcpdump आउटपुट में मैसेज #3 (क्लाइंट हैलो) की ज़्यादा जानकारी देखें. ध्यान दें कि एक्सटेंशन: Server_name मौजूद नहीं है, जैसा कि नीचे दिखाया गया है:

      

   9. इससे पुष्टि होती है कि मैसेज प्रोसेसर ने server_name लिंक करें.
   10. TLS/एसएसएल हैंडशेक के काम न करने और बैकएंड में हुई गड़बड़ी की वजह यही है सर्वर, मैसेज को गंभीर चेतावनी: हैंडशेक फ़ेलियर मैसेज भेजता है प्रोसेसर.
5. पुष्टि करें कि jsse.enableSNIExtension property मैसेज प्रोसेसर पर system.properties को 'गलत' पर सेट किया गया है, ताकि यह पुष्टि की जा सके कि मैसेज प्रोसेसर, SNI-चालू सर्वर से संपर्क करने के लिए चालू नहीं है.

रिज़ॉल्यूशन

यह इसके लिए, नीचे दिया गया तरीका अपनाएं:

1. /opt/apigee/customer/application/message-processor.properties बनाएं फ़ाइल (अगर यह पहले से मौजूद नहीं है).
2. इस फ़ाइल में यह लाइन जोड़ें: conf_system_jsse.enableSNIExtension=true अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
3. इस फ़ाइल के मालिक को चुनें और apigee:apigee को भेजें:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. मैसेज प्रोसेसर को रीस्टार्ट करें.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. अगर आपके पास एक से ज़्यादा मैसेज प्रोसेसर हैं, तो सभी चरणों को #1 से #4 तक दोहराएं मैसेज प्रोसेसर.

यदि आप TLS/एसएसएल हैंडशेक की गड़बड़ी की वजह का पता नहीं लगा पा रहे हैं और समस्या को ठीक कर सकते हैं या आपको कोई और मदद चाहिए, तो हमारी सहायता टीम से संपर्क करें Apigee Edge की सहायता टीम. समस्या के बारे में पूरी जानकारी शेयर करें tcpdump आउटपुट.