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

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

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

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

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

HTTP/1.1 503 Service Unavailable

TLS/SSL हैंडशेक पूरा न होने पर, आपको गड़बड़ी का यह मैसेज भी दिख सकता है:

Received fatal alert: handshake_failure

संभावित कारण

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

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

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

TLS/SSL हैंडशेक पूरा न होने की ये वजहें हो सकती हैं:

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

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

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

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

   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 से पता चलता है कि बैकएंड सर्वर, मैसेज प्रोसेसर से मिले "क्लाइंट हैलो" मैसेज को स्वीकार करता है.
   • बैकएंड सर्वर, मैसेज प्रोसेसर को तुरंत Fatal Alert : Close Notify भेजता है (मैसेज #6). इसका मतलब है कि टीएलएस/एसएसएल हैंडशेक नहीं हो सका और कनेक्शन बंद हो जाएगा.

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

     

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

रिज़ॉल्यूशन

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

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

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

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

साइफ़र मैच नहीं हो रहा है

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

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

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

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

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

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

     

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

     

   • पांचवें मैसेज से पता चलता है कि Edge Router, क्लाइंट ऐप्लिकेशन से मिले "Client Hello" मैसेज को स्वीकार करता है.
   • इसके बाद, Edge राउटर क्लाइंट ऐप्लिकेशन को तुरंत Fatal Alert : Handshake Failure भेजता है (मैसेज #6). इसका मतलब है कि टीएलएस/एसएसएल हैंडशेक नहीं हो सका और कनेक्शन बंद हो जाएगा.
   • मैसेज #6 की ज़्यादा जानकारी देखने पर, यह पता चलता है:
     • Edge Router, TLSv1.2 प्रोटोकॉल के साथ काम करता है. इसका मतलब है कि क्लाइंट ऐप्लिकेशन और Edge Router के बीच प्रोटोकॉल मैच करता है.

     • हालांकि, Edge राऊटर अब भी क्लाइंट ऐप्लिकेशन को Fatal Alert: Handshake Failure भेजता है. इसे नीचे दिए गए स्क्रीनशॉट में दिखाया गया है:

       

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

     

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

रिज़ॉल्यूशन

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

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

अगर आपके कीस्टोर/ट्रस्टस्टोर में गलत सर्टिफ़िकेट हैं, तो टीएलएस/एसएसएल हैंडशेक पूरा नहीं हो पाता. ऐसा 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 Management API कॉल से मिले यूआरएल में इस्तेमाल किए गए होस्टनेम को नोट करें:

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

   उदाहरण के लिए:

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

2. किसी खास कीस्टोर में सेव किए गए सर्टिफ़िकेट में इस्तेमाल किया गया सीएन पाएं. सर्टिफ़िकेट की जानकारी पाने के लिए, Edge मैनेजमेंट एपीआई का इस्तेमाल किया जा सकता है:
   1. कीस्टोर में सर्टिफ़िकेट का नाम पाएं:
      
      अगर आप Private 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 का इस्तेमाल करके, कीस्टोर में मौजूद सर्टिफ़िकेट की जानकारी पाएं.
      
      अगर आप Private Cloud के उपयोगकर्ता हैं, तो:
      

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

      अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो:
      

      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. है

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

रिज़ॉल्यूशन

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

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

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

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

रेफ़रंस

कीस्टोर और ट्रस्टस्टोर

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

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

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

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

      अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो:
      

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

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

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

      अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो:
      

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

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

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

   
   

रिज़ॉल्यूशन

1. ऐसा सर्टिफ़िकेट पाएं (अगर आपके पास पहले से नहीं है) जिसमें पूरी और मान्य सर्टिफ़िकेट चेन शामिल हो.
2. यह openssl कमांड चलाकर पुष्टि करें कि सर्टिफ़िकेट चेन सही और पूरी है:

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

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

सर्वर या क्लाइंट की ओर से भेजा गया प्रमाणपत्र, जिसकी समयसीमा खत्म हो गई है या जिसके बारे में कोई जानकारी नहीं है

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

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

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

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

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

   सर्टिफ़िकेट की पुष्टि नहीं की जा सकी गड़बड़ी दिखाने वाला सैंपल tcpdump

   
   

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

      
      

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

      

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

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

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

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

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

रिज़ॉल्यूशन

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

यहां दी गई टेबल में, समस्या की वजह के आधार पर उसे हल करने का तरीका बताया गया है.

एसएनआई की सुविधा चालू है सर्वर

टीएलएस/एसएसएल हैंडशेक की प्रोसेस तब पूरी नहीं हो पाती, जब क्लाइंट, सर्वर नेम इंडिकेशन (एसएनआई) की सुविधा वाले सर्वर से कम्यूनिकेट कर रहा हो, लेकिन क्लाइंट के पास एसएनआई की सुविधा न हो. ऐसा Edge में नॉर्थबाउंड या साउथबाउंड कनेक्शन के दौरान हो सकता है.

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

SNI की सुविधा वाले सर्वर की पहचान करना

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

   openssl s_client -connect hostname:port

   आपको सर्टिफ़िकेट मिल सकते हैं. हालांकि, कभी-कभी आपको openssl कमांड में हैंडशेक फ़ेल होने की समस्या दिख सकती है. जैसा कि यहां दिखाया गया है:
   

   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. यह पता लगाएं कि गड़बड़ी नॉर्थबाउंड या साउथबाउंड कनेक्शन में हुई है. यह फ़ैसला लेने के बारे में ज़्यादा जानकारी पाने के लिए, समस्या के सोर्स का पता लगाना लेख पढ़ें.
2. ज़्यादा जानकारी इकट्ठा करने के लिए, tcpdump यूटिलिटी चलाएं:
   • अगर आप Private Cloud के उपयोगकर्ता हैं, तो आपके पास tcpdump डेटा को ज़रूरी क्लाइंट या सर्वर पर इकट्ठा करने का विकल्प होता है. क्लाइंट, क्लाइंट ऐप्लिकेशन (इनकमिंग या नॉर्थबाउंड कनेक्शन के लिए) या मैसेज प्रोसेसर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए) हो सकता है. पहले चरण में तय की गई बातों के आधार पर, सर्वर को एज राउटर (इनकमिंग या नॉर्थबाउंड कनेक्शन के लिए) या बैकएंड सर्वर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए) के तौर पर इस्तेमाल किया जा सकता है.
   • अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो tcpdump डेटा सिर्फ़ क्लाइंट ऐप्लिकेशन (इनकमिंग या नॉर्थबाउंड कनेक्शन के लिए) या बैकएंड सर्वर (आउटगोइंग या साउथबाउंड कनेक्शन के लिए) पर इकट्ठा किया जा सकता है. ऐसा इसलिए, क्योंकि आपके पास एज राउटर या मैसेज प्रोसेसर का ऐक्सेस नहीं होता.

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

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

      

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

      

   4. मैसेज #4 से पता चलता है कि बैकएंड सर्वर, मैसेज प्रोसेसर से मिले "क्लाइंट हैलो" मैसेज को स्वीकार करता है.
   5. बैकएंड सर्वर, मैसेज प्रोसेसर को तुरंत Fatal Alert : Handshake Failure भेजता है (मैसेज #5). इसका मतलब है कि टीएलएस/एसएसएल हैंडशेक नहीं हो सका और कनेक्शन बंद हो जाएगा.
   6. छठे मैसेज की समीक्षा करके, यह जानकारी पाएं
      • बैकएंड सर्वर, TLSv1.2 प्रोटोकॉल के साथ काम करता है. इसका मतलब है कि Message Processor और बैकएंड सर्वर के बीच प्रोटोकॉल मैच हो गया है.
      • हालांकि, बैकएंड सर्वर अब भी मैसेज प्रोसेसर को Fatal Alert: Handshake Failure भेजता है. इसे नीचे दिए गए डायग्राम में दिखाया गया है:

        

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

      

   9. इससे पुष्टि होती है कि मैसेज प्रोसेसर ने SNI की सुविधा वाले बैकएंड सर्वर को server_name नहीं भेजा.
   10. इस वजह से, टीएलएस/एसएसएल हैंडशेक पूरा नहीं हो पाता. साथ ही, इस वजह से बैकएंड सर्वर, मैसेज प्रोसेसर को Fatal Alert: Handshake Failure भेजता है.
5. पुष्टि करें कि मैसेज प्रोसेसर पर jsse.enableSNIExtension property in 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. अगर आपके पास एक से ज़्यादा मैसेज प्रोसेसर हैं, तो सभी मैसेज प्रोसेसर पर पहले से चौथे चरण तक की प्रोसेस दोहराएं.

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