503 सेवा उपलब्ध नहीं है - एसएसएल हैंडशेक की गड़बड़ी

एपीआई मॉनिटरिंग

प्रोसेस #1: एपीआई मॉनिटरिंग का इस्तेमाल करना

एपीआई मॉनिटरिंग का इस्तेमाल करके, गड़बड़ी का पता लगाने के लिए:

1. वाले उपयोगकर्ता के तौर पर, Apigee Edge के यूज़र इंटरफ़ेस (यूआई) में साइन इन करें भूमिका होनी चाहिए.

2. उस संगठन पर जाएं जिसमें आपको समस्या की जांच करनी है.

   
3. विश्लेषण करें > एपीआई मॉनिटरिंग > पेज की जांच करें.
4. वह समयावधि चुनें जिसमें आपको गड़बड़ियां दिखी थीं.

5. समय के हिसाब से गड़बड़ी कोड दिखाएं.

6. वह सेल चुनें जिसमें गड़बड़ी का कोड है messaging.adaptors.http.flow.SslHandshakeFailed जैसा दिखाया गया नीचे दिया गया है:

   ( बड़ी इमेज देखें)

   

7. गड़बड़ी के कोड के बारे में जानकारी messaging.adaptors.http.flow.SslHandshakeFailed को इस तौर पर दिखाया गया है नीचे दी गई जानकारी देखें:

   ( बड़ी इमेज देखें)

   

8. लॉग देखें पर क्लिक करें और फ़ेल हो चुके अनुरोध की पंक्ति को बड़ा करें.

   ( बड़ी इमेज देखें)

   
9. लॉग विंडो में जाकर, यह जानकारी देखें:
   • मैसेज आईडी का अनुरोध करें
   • स्टेटस कोड: 503
   • गलत सोर्स: target
   • गलत कोड: messaging.adaptors.http.flow.SslHandshakeFailed

ट्रेस

प्रोसेस #2: ट्रेस टूल का इस्तेमाल करना

ट्रेस टूल का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:

1. ट्रेस सेशन को चालू करें और
   • गड़बड़ी के कोड वाली 503 Service Unavailable गड़बड़ी का इंतज़ार करें messaging.adaptors.http.flow.SslHandshakeFailed या
   • अगर आपको समस्या के बारे में अच्छे से पता है, तो समस्या के बारे में बताने के लिए एपीआई कॉल करें 503 Service Unavailable अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

2. पक्का करें कि सभी FlowInfos दिखाएं चालू है:

   
3. पूरे न हो पाने वाले अनुरोधों में से किसी एक को चुनें और ट्रेस की जांच करें.
4. ट्रेस के अलग-अलग फ़ेज़ पर जाएं और देखें कि गड़बड़ी कहां हुई.

5. आपको गड़बड़ी आम तौर पर टारगेट अनुरोध फ़्लो शुरू होने के चरण के बाद मिलेगी जैसा कि नीचे दिखाया गया है:

   ( बड़ी इमेज देखें)

   
6. ट्रेस में दी गई इन वैल्यू को नोट करें:
   • गड़बड़ी: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class: com.apigee.errors.http.server.ServiceUnavailableException
   • गड़बड़ी SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target की वैल्यू बताती है कि एसएसएल हैंडशेक नहीं हो सका, क्योंकि Apigee Edge का मैसेज प्रोसेसर, बैकएंड सर्वर के प्रमाणपत्र.
7. ट्रेस में AX (Analytics डेटा रिकॉर्ड किया गया) चरण पर जाएं और उस पर क्लिक करें.

8. नीचे चरण की जानकारी के गड़बड़ी वाले हेडर सेक्शन तक स्क्रोल करें और तय करें कि X-Apigee-fault-code और X-Apigee-fault-source की वैल्यू, और X-Apigee-Message-ID, जैसा कि नीचे दिखाया गया है:

   ( बड़ी इमेज देखें)

   
9. X-Apigee-fault-code, X-Apigee-fault-source की वैल्यू नोट करें, और X-Apigee-Message-ID:

गड़बड़ी के हेडर	मान
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

प्रक्रिया #3: NGINX ऐक्सेस लॉग का इस्तेमाल करना

NGINX ऐक्सेस लॉग का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:

1. अगर आप निजी Cloud उपयोगकर्ता हैं, तो यह पता करने के लिए कि NGINX ऐक्सेस लॉग का इस्तेमाल किया जा सकता है या नहीं एचटीटीपी 503 Service Unavailable के बारे में अहम जानकारी.

2. NGINX ऐक्सेस लॉग देखें:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

3. यह देखने के लिए खोजें कि क्या गड़बड़ी कोड में कोई 503 गड़बड़ी है किसी खास अवधि के दौरान messaging.adaptors.http.flow.SslHandshakeFailed (अगर समस्या पुराना) या अगर कोई अनुरोध अब भी 503 के साथ पूरा नहीं हो पा रहा है.

4. अगर आपको मेल खाने वाले X-Apigee-fault-code के साथ कोई 503 गड़बड़ी मिलती है मान messaging.adaptors.http.flow.SslHandshakeFailed, फिर X-Apigee-fault-source. की वैल्यू तय करें.

   NGINX ऐक्सेस लॉग में 503 गड़बड़ी का नमूना:

   ( बड़ी इमेज देखें)

   

   NGINX ऐक्सेस लॉग की ऊपर दी गई सैंपल एंट्री में, X-Apigee-fault-code और X-Apigee-fault-source:

   हेडर	मान
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

मैसेज प्रोसेसर के लॉग

प्रक्रिया #4: मैसेज प्रोसेसर लॉग का इस्तेमाल करना

1. एपीआई मॉनिटरिंग, ट्रेस टूल, और काम न करने वाले अनुरोधों में से किसी एक का मैसेज आईडी पता करें या NGINX ऐक्सेस लॉग का डेटा इकट्ठा करना होगा. इसके बारे में गड़बड़ी की जानकारी के सामान्य तरीके में बताया गया है.

2. मैसेज प्रोसेसर लॉग में, अनुरोध वाला मैसेज आईडी खोजें (/opt/apigee/var/log/edge-message-processor/logs/system.log). आपको यह साफ़ तौर पर पता चल सकता है यह गड़बड़ी दिख रही है:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   ऊपर दी गई गड़बड़ी बताती है कि मैसेज प्रोसेसर के बीच एसएसएल हैंडशेक विफल रहा और बैकएंड सर्वर पर भी काम करता है.

   इसके बाद, ब्यौरे वाला स्टैक ट्रेस अपवाद होगा, जैसा कि नीचे दिखाया गया है:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   ध्यान दें कि हैंडशेक इन वजहों से नहीं हो पा रहा:

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   इससे पता चलता है कि एसएसएल हैंडशेक, Apigee Edge का मैसेज प्रोसेसर था बैकएंड सर्वर के सर्टिफ़िकेट की पुष्टि नहीं की जा सकी.

पहला चरण

पहला चरण: बैकएंड सर्वर की सर्टिफ़िकेट चेन तय करना

बैकएंड सर्वर की सर्टिफ़िकेट चेन तय करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल करें:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

दूसरा चरण

दूसरा चरण: बैकएंड सर्वर के सर्टिफ़िकेट और मैसेज प्रोसेसर का ट्रस्टस्टोर

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

   1. TrustStore एलिमेंट से ट्रस्टस्टोर रेफ़रंस नाम पाएं TargetEndpoint के SSLInfo सेक्शन में.

      चलिए, TargetEndpoint के SSLInfo सेक्शन का सैंपल देखते हैं कॉन्फ़िगरेशन:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>
      

   2. ऊपर दिए गए उदाहरण में, TrustStore पहचान नाम यह है myCompanyTruststoreRef.

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

      ( बड़ी इमेज देखें)

      

   4. ऊपर दिए गए उदाहरण में Truststore का नाम है:

      myCompanyTruststoreRef: myCompanyTruststore

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

   1. कीस्टोर या ट्रस्टस्टोर के लिए सभी सर्टिफ़िकेट पाएं. इस एपीआई में सभी सर्टिफ़िकेट.

      सार्वजनिक क्लाउड उपयोगकर्ता:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      निजी Cloud उपयोगकर्ता:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      कहां:

      • ORGANIZATION_NAME, संगठन का नाम है
      • ENVIRONMENT_NAME एनवायरमेंट का नाम है
      • KEYSTORE_NAME, कीस्टोर का नाम है
      • $TOKEN, आपके OAuth 2.0 ऐक्सेस टोकन पर सेट होता है. इसकी जानकारी यहां दी गई है OAuth 2.0 ऐक्सेस टोकन पाना
      • इस उदाहरण में इस्तेमाल किए गए curl विकल्प के बारे में यहां बताया गया है कर्ल का इस्तेमाल करना

      आउटपुट का नमूना:

      उदाहरण ट्रस्टस्टोर myCompanyTruststore के सर्टिफ़िकेट:

      [
        "serverCert"
      ]
      

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

      सार्वजनिक क्लाउड उपयोगकर्ता:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      निजी Cloud उपयोगकर्ता

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      कहां:

      • ORGANIZATION_NAME, संगठन का नाम है
      • ENVIRONMENT_NAME एनवायरमेंट का नाम है
      • KEYSTORE_NAME, कीस्टोर का नाम है
      • सर्टिफ़िकेट का नाम CERT_NAME है
      • $TOKEN, आपके OAuth 2.0 ऐक्सेस टोकन पर सेट होता है. इसकी जानकारी यहां दी गई है OAuth 2.0 ऐक्सेस टोकन पाना
      • इस उदाहरण में इस्तेमाल किए गए curl विकल्प के बारे में यहां बताया गया है कर्ल का इस्तेमाल करना

      आउटपुट का सैंपल

      serverCert के दस्तावेज़ में, विषय और उसे जारी करने वाले के बारे में यह जानकारी दी गई है:

      लीफ़/इकाई का सर्टिफ़िकेट:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      इंटरमीडिएट सर्टिफ़िकेट:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

4. पुष्टि करें कि चरण 1 में मिला असल सर्वर सर्टिफ़िकेट और सर्टिफ़िकेट को तीसरे चरण में मिलान करने के बाद मिले Truststore में स्टोर किया गया है. अगर वे मेल नहीं खाते हैं, तो यह की वजह डालें.

   ऊपर दिखाए गए उदाहरण से, आइए एक बार में एक ही सर्टिफ़िकेट पर नज़र डालते हैं:

   1. लीफ़ सर्टिफ़िकेट:

      बैकएंड सर्वर से:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      

      मैसेज प्रोसेसर (क्लाइंट) के ट्रस्टस्टोर से:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      Truststore में सेव किया गया लीफ़ सर्टिफ़िकेट, बैकएंड के सर्टिफ़िकेट से मेल खाता है सर्वर.

   2. इंटरमीडिएट सर्टिफ़िकेट:

      बैकएंड सर्वर से:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      मैसेज प्रोसेसर (क्लाइंट) के ट्रस्टस्टोर से:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

      Truststore में सेव किया गया इंटरमीडिएट सर्टिफ़िकेट बैकएंड सर्वर.

   3. रूट सर्टिफ़िकेट:

      बैकएंड सर्वर से:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      मैसेज प्रोसेसर में रूट सर्टिफ़िकेट पूरी तरह से मौजूद नहीं है Truststore.

   4. Truststore में रूट सर्टिफ़िकेट मौजूद नहीं है, इसलिए मैसेज प्रोसेसर की ओर से यह अपवाद दिखता है:

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
      

      और गड़बड़ी कोड के साथ 503 Service Unavailable दिखाता है क्लाइंट के लिए messaging.adaptors.http.flow.SslHandshakeFailed का इस्तेमाल करें.

सही FQDN

बैकएंड सर्वर के कीस्टोर को सही FQDN के साथ अपडेट करें. साथ ही, मान्य और पूरा सर्टिफ़िकेट भी अपडेट करें चेन:

1. अगर आपके पास बैकएंड सर्वर का सही एफ़क्यूडीएन वाला सर्टिफ़िकेट नहीं है, तो तो किसी संबंधित सीए (सर्टिफ़िकेट अथॉरिटी) से सही सर्टिफ़िकेट लेना होगा.

2. पुष्टि करें कि आपके पास मान्य और पूरी बैकएंड सर्वर की सर्टिफ़िकेट चेन.

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

सही बैकएंड सर्वर

टारगेट एंडपॉइंट को सही बैकएंड सर्वर के होस्ट नाम के साथ अपडेट करें:

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

2. एपीआई प्रॉक्सी में किए गए बदलावों को सेव करें.

   ऊपर बताए गए उदाहरण में, अगर बैकएंड सर्वर का होस्ट नाम गलत था, तो बताया गया है, तो बैकएंड सर्वर के सर्टिफ़िकेट से FQDN का इस्तेमाल करके इसे ठीक किया जा सकता है, इसका नतीजा backend.apigee.net है:

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>