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

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

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

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

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

HTTP/1.1 503 Service Unavailable

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

Received fatal alert: handshake_failure

संभावित कारण

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

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

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

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

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

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

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

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

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

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

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

     

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

     

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

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

     

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

रिज़ॉल्यूशन

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

1. TLSv1.2 प्रोटोकॉल के साथ काम करने के लिए, अपना बैकएंड सर्वर अपग्रेड करें. हम इसका सुझाव देते हैं, क्योंकि TLSv1.2 प्रोटोकॉल ज़्यादा सुरक्षित है.
2. अगर किसी वजह से अपना बैकएंड सर्वर तुरंत अपग्रेड नहीं हो पा रहा, तो यह तरीका अपनाकर मैसेज प्रोसेसर को ज़बरदस्ती TLSv1.0 प्रोटोकॉल का इस्तेमाल करके, बैकएंड सर्वर से संपर्क करने के लिए कहा जा सकता है:
   1. अगर आपने प्रॉक्सी की टारगेट एंडपॉइंट डेफ़िनिशन में टारगेट सर्वर के बारे में जानकारी नहीं दी है, तो 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 में इनकमिंग (नॉर्थबाउंड) या आउटगोइंग (आउटहबाउंड) कनेक्शन पर काम नहीं करता है, तो आपको TLS/एसएसएल हैंडशेक फ़ेल होने की जानकारी दिख सकती है. उत्तर की ओर और दक्षिण की ओर जाने वाले कनेक्शन को समझना भी देखें.

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

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

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

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

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

     

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

     

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

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

       

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

     

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

रिज़ॉल्यूशन

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

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

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

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

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

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

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

* 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

संभावित कारण

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

Cause	जानकारी	समस्या हल करने वाले चरणों को कौन पूरा कर सकता है
होस्टनेम मैच नहीं होता	यूआरएल में इस्तेमाल किया गया होस्टनेम और राऊटर के कीस्टोर में मौजूद सर्टिफ़िकेट, एक-दूसरे से मेल नहीं खाते. उदाहरण के लिए, ऐसा तब होता है, जब यूआरएल में इस्तेमाल किए गए होस्ट का नाम myorg.domain.com हो, जबकि सर्टिफ़िकेट के CN में होस्टनेम CN=something.domain.com. के तौर पर हो	Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
अधूरा या गलत सर्टिफ़िकेट चेन	सर्टिफ़िकेट की चेन पूरी नहीं है या सही नहीं है.	सिर्फ़ Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
सर्वर या क्लाइंट से मिले सर्टिफ़िकेट की समयसीमा खत्म हो चुकी है या उसकी जानकारी नहीं है	सर्वर या क्लाइंट, ऐसा सर्टिफ़िकेट भेजता है जिसकी समयसीमा खत्म हो चुकी है या जिसकी जानकारी नहीं है. यह सर्टिफ़िकेट या तो उत्तर की तरफ़ या दक्षिण की तरफ़ कनेक्शन पर भेजा जाता है.	Edge प्राइवेट क्लाउड और Edge सार्वजनिक क्लाउड के उपयोगकर्ता

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

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

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

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

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

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

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

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

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

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

रिज़ॉल्यूशन

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

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

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

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

References

कीस्टोर और Truststore

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

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

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

      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. कीस्टोर में सर्टिफ़िकेट की जानकारी पाएं:
      
      अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं:
      

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

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

   
   

रिज़ॉल्यूशन

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

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

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

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

अगर सर्वर या क्लाइंट ने गलत सर्टिफ़िकेट या समयसीमा खत्म होने की तारीख को उत्तर की तरफ़ या दक्षिण की तरफ़ वाले कनेक्शन पर भेजा है, तो सर्वर/क्लाइंट उस सर्टिफ़िकेट को अस्वीकार कर देता है. इस वजह से TLS/एसएसएल हैंडशेक काम नहीं करता.

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

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

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

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

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

   
   

   1. मैसेज प्रोसेसर (क्लाइंट) की ओर से मैसेज #59 में, बैकएंड सर्वर (सर्वर) को "क्लाइंट हैलो" भेजा जाता है.
   2. बैकएंड सर्वर, मैसेज #61 के तहत मैसेज प्रोसेसर को "सर्वर हैलो" भेजता है.
   3. वे इस्तेमाल किए गए प्रोटोकॉल और साइफ़र सुइट एल्गोरिदम की आपसी पुष्टि करते हैं.
   4. बैकएंड सर्वर, मैसेज #68 के तहत मैसेज प्रोसेसर को सर्टिफ़िकेट और सर्वर हैलो हो गया मैसेज भेजता है.
   5. मैसेज प्रोसेसर, मैसेज #70 में गंभीर चेतावनी "जानकारी: सर्टिफ़िकेट पता नहीं है" भेजता है.
   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 आउटपुट से मिले सर्टिफ़िकेट से मेल खाता है या नहीं. अगर दोनों मेल नहीं खाते हैं, तो इसकी वजह TLS/एसएसएल हैंडशेक काम करना बंद कर सकती है.
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. पुष्टि करें कि सही होस्ट के कीस्टोर में मौजूद सर्टिफ़िकेट की समयसीमा खत्म हो गई है.

रिज़ॉल्यूशन

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

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

Cause	जानकारी	रिज़ॉल्यूशन
सर्टिफ़िकेट की समयसीमा खत्म हो गई है	NorthBound राऊटर के कीस्टोर में सेव किए गए सर्टिफ़िकेट की समयसीमा खत्म हो गई है. क्लाइंट ऐप्लिकेशन के कीस्टोर में सेव किए गए सर्टिफ़िकेट की समयसीमा खत्म हो गई है (2-वे एसएसएल).	सही होस्ट के कीस्टोर में, एक नया सर्टिफ़िकेट और उसकी पूरी चेन अपलोड करें.
	SouthBound टारगेट सर्वर के कीस्टोर में सेव किए गए सर्टिफ़िकेट की समयसीमा खत्म हो गई है. Message प्रोसेसर के कीस्टोर में सेव किए गए सर्टिफ़िकेट की समयसीमा खत्म हो गई है (2-वे एसएसएल).	सही होस्ट के कीस्टोर में, एक नया सर्टिफ़िकेट और उसकी पूरी चेन अपलोड करें.
अज्ञात सर्टिफ़िकेट	NorthBound क्लाइंट ऐप्लिकेशन के ट्रस्टस्टोर में सेव किया गया सर्टिफ़िकेट, राऊटर के सर्टिफ़िकेट से मेल नहीं खाता. राऊटर के ट्रस्टस्टोर में सेव किया गया सर्टिफ़िकेट, क्लाइंट ऐप्लिकेशन के सर्टिफ़िकेट (2तरफ़ा एसएसएल) से मेल नहीं खाता.	सही होस्ट पर ट्रस्टस्टोर में मान्य सर्टिफ़िकेट अपलोड करें.
	SouthBound टारगेट सर्वर के ट्रस्टस्टोर में सेव किया गया सर्टिफ़िकेट, Message प्रोसेसर के सर्टिफ़िकेट से मेल नहीं खाता. Message प्रोसेसर के ट्रस्टस्टोर में सेव किया गया सर्टिफ़िकेट, टारगेट सर्वर के सर्टिफ़िकेट (2-वे एसएसएल) से मेल नहीं खाता.	सही होस्ट पर ट्रस्टस्टोर में मान्य सर्टिफ़िकेट अपलोड करें.

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 कमांड लागू करें. इसके बाद, यहां दिखाए गए सर्वर का नाम पास करके, काम के सर्वर के होस्टनेम (Edge राऊटर या बैकएंड सर्वर) से कनेक्ट करने की कोशिश करें:

   openssl s_client -connect hostname:port -servername hostname
   

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

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

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

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

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

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

      

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

      

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

        

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

      

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

रिज़ॉल्यूशन

नीचे दिए गए तरीके का इस्तेमाल करके, मैसेज प्रोसेसर को 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 आउटपुट के साथ, समस्या के बारे में पूरी जानकारी शेयर करें.