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

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

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

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के रिस्पॉन्स के तौर पर, गड़बड़ी कोड messaging.adaptors.http.flow.SslHandshakeFailed के साथ 503 Service Unavailable का एचटीटीपी स्टेटस कोड मिलता है.

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

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है: 

HTTP/1.1 503 Service Unavailable

इसके अलावा, आपको गड़बड़ी का यह मैसेज भी दिख सकता है: 

{
   "fault":{
      "faultstring":"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",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"
      }
   }
}

संभावित कारण

आपको गड़बड़ी कोड messaging.adaptors.http.flow.SslHandshakeFailed के साथ स्टेटस कोड 503 Service Unavailable मिल सकता है. यह कई वजहों से हो सकता है. इसकी वजह यह है कि Apigee Edge के Message प्रोसेसर और बैकएंड सर्वर के बीच एसएसएल हैंडशेक करने की प्रोसेस के दौरान, सिस्टम में गड़बड़ी हुई. आम तौर पर, faultstring में गड़बड़ी का मैसेज, किसी ऐसी बड़ी समस्या के बारे में बताता है जिसकी वजह से यह गड़बड़ी हुई है.

faultstring में गड़बड़ी के मैसेज के आधार पर, आपको समस्या को हल करने के लिए सही तकनीकों का इस्तेमाल करना होगा. इस प्लेबुक में बताया गया है कि अगर आपको faultstring में गड़बड़ी का मैसेज 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 के मैसेज प्रोसेसर और बैकएंड सर्वर के बीच एसएसएल हैंडशेक करने की प्रोसेस के दौरान होती है:

  • अगर Apigee Edge के मैसेज प्रोसेसर का truststore है, तो:
    • इसमें ऐसी सर्टिफ़िकेट चेन शामिल हो जो बैकएंड सर्वर के पूरे सर्टिफ़िकेट की चेन से मेल न खाती हो या
    • इसमें बैकएंड सर्वर की पूरी सर्टिफ़िकेट चेन शामिल नहीं है
  • अगर बैकएंड सर्वर से प्रज़ेंट की गई सर्टिफ़िकेट चेन है:

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

वजह ब्यौरा समस्या हल करने के लिए निर्देश
Messages प्रोसेसर के ट्रस्टस्टोर में गलत/अधूरे सर्टिफ़िकेट या सर्टिफ़िकेट चेन Apigee Edge के Message प्रोसेसर के ट्रस्टस्टोर में सेव किया गया सर्टिफ़िकेट और/या उसकी चेन, बैकएंड सर्वर के सर्टिफ़िकेट की चेन से मेल नहीं खाती या उसमें बैकएंड सर्वर की पूरी सर्टिफ़िकेट चेन शामिल नहीं है. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
बैकएंड सर्वर के सर्टिफ़िकेट और टारगेट एंडपॉइंट में मौजूद होस्ट नेम, एफ़क्यूडीएन से मेल नहीं खाता बैकएंड सर्वर से मिलने वाले सर्टिफ़िकेट में एक FQDN होता है, जो टारगेट एंडपॉइंट में दिए गए होस्ट नेम से मेल नहीं खाता. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
बैकएंड सर्वर से मिला सर्टिफ़िकेट या गलत/अधूरे सर्टिफ़िकेट बैकएंड सर्वर से मिली सर्टिफ़िकेट चेन गलत है या अधूरी है. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता

निदान के सामान्य चरण

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

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

प्रोसेस #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 की वैल्यू नोट करें:
    10. गड़बड़ी वाले हेडर वैल्यू
    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. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो एचटीटीपी 503 Service Unavailable के बारे में अहम जानकारी तय करने के लिए, NGINX ऐक्सेस लॉग का इस्तेमाल कर सकते हैं.

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

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

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

  4. अगर आपको X-Apigee-fault-code में, messaging.adaptors.http.flow.SslHandshakeFailed की वैल्यू से मेल खाने वाली कोई 503 गड़बड़ी दिखती है, तो 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 के मैसेज प्रोसेसर के तौर पर, एसएसएल हैंडशेक काम नहीं कर सका. ऐसा इसलिए हुआ, क्योंकि यह बैकएंड सर्वर के सर्टिफ़िकेट की पुष्टि नहीं कर सका.

वजह: Message प्रोसेसर के ट्रस्टस्टोर में गलत/अधूरे सर्टिफ़िकेट या सर्टिफ़िकेट चेन

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

  1. एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके मिली गड़बड़ी के लिए, फ़ॉल कोड, गड़बड़ी का सोर्स तय करें. इस बारे में गड़बड़ी की जानकारी पाने के सामान्य तरीके में बताया गया है.
  2. अगर गलत कोड messaging.adaptors.http.flow.SslHandshakeFailed है, तो इनमें से किसी एक तरीके का इस्तेमाल करके गड़बड़ी के मैसेज का पता लगाएं:
  3. अगर गड़बड़ी का मैसेज sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" है, तो इसका मतलब है कि एसएसएल हैंडशेक काम नहीं कर सका. इसकी वजह यह है कि Apigee Edge का मैसेज प्रोसेसर, बैकएंड सर्वर के सर्टिफ़िकेट की पुष्टि नहीं कर सका.

इस समस्या को दो चरणों में डीबग किया जा सकता है:

  1. पहला चरण: बैकएंड सर्वर की सर्टिफ़िकेट चेन तय करना
  2. चरण 2: Message प्रोसेसर के ट्रस्टस्टोर में स्टोर की गई सर्टिफ़िकेट चेन की तुलना करें

पहला चरण

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

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

openssl

बैकएंड सर्वर के होस्ट नेम के लिए, openssl कमांड को इस तरह लागू करें:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

ऊपर दिए गए निर्देश के आउटपुट से सर्टिफ़िकेट चेन को नोट करें:

openएसएसएल कमांड आउटपुट से सैंपल बैकएंड सर्वर सर्टिफ़िकेट चेन:

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

tcpdump

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

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

    tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

  4. वायर शार्क टूल या इससे मिलते-जुलते टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट का विश्लेषण करें.

    Tcpdump का सैंपल विश्लेषण

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

    • पैकेट #43: मैसेज प्रोसेसर (सोर्स) ने बैकएंड सर्वर (डेस्टिनेशन) पर Client Hello मैसेज भेजा.
    • पैकेट #44: बैकएंड सर्वर, मैसेज प्रोसेसर से Client Hello मैसेज मिलने की सूचना देता है.
    • पैकेट #45: बैकएंड सर्वर अपने सर्टिफ़िकेट के साथ Server Hello मैसेज भेजता है.
    • पैकेट #46: मैसेज प्रोसेसर, Server Hello मैसेज और सर्टिफ़िकेट की रसीद स्वीकार करता है.

    • पैकेट #47: मैसेज प्रोसेसर एक FIN, ACK मैसेज भेजता है. इसके बाद, Packet #48 में RST, ACK मैसेज भेजा जाता है.

      इससे पता चलता है कि मैसेज प्रोसेसर से बैकएंड सर्वर सर्टिफ़िकेट की पुष्टि नहीं हो सकी. इसकी वजह यह है कि Message प्रोसेसर के पास ऐसा कोई सर्टिफ़िकेट नहीं है जो बैकएंड सर्वर के सर्टिफ़िकेट से मेल खाता हो. इसके अलावा, वह अपने (मैसेज प्रोसेसर के) ट्रस्टस्टोर में उपलब्ध सर्टिफ़िकेट के साथ बैकएंड सर्वर के सर्टिफ़िकेट पर भरोसा नहीं कर सकता. ऐसा इसलिए होता है.

    • आपके पास वापस जाकर, Packet #45 की समीक्षा करने और बैकएंड सर्वर से भेजी गई सर्टिफ़िकेट चेन तय करने का विकल्प है

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

    • इस उदाहरण में, यह देखा जा सकता है कि सर्वर ने common name (CN) = mocktarget.apigee.net वाला लीफ़ सर्टिफ़िकेट भेजा है. इसके बाद CN= GTS CA 1D4 वाला इंटरमीडिएट सर्टिफ़िकेट भेजा गया है. साथ ही, CN = GTX Root R1 वाला रूट सर्टिफ़िकेट भेजा गया है.

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

दूसरा चरण

दूसरा चरण: Message प्रोसेसर के ट्रस्टस्टोर में सेव किए गए बैकएंड सर्वर के सर्टिफ़िकेट और सर्टिफ़िकेट की तुलना करना

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

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

      आइए, 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 के यूज़र इंटरफ़ेस (यूआई) में, परिवेश > रेफ़रंस चुनें. खास ट्रस्टस्टोर रेफ़रंस के लिए, रेफ़रंस कॉलम में मौजूद नाम नोट करें. यह आपके ट्रस्टस्टोर का नाम होगा.

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

    4. ऊपर दिए गए उदाहरण में ट्रस्टस्टोर का नाम यह है:

      myCompanyTruststoreRef: myCompanyTruststore

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

    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"

      प्राइवेट क्लाउड उपयोगकर्ता:

      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 विकल्पों के बारे में, curl का इस्तेमाल करें में बताया गया है

      सैंपल आउटपुट:

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

      [
  "serverCert"
]

    2. किसी कीस्टोर या 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"

      प्राइवेट क्लाउड उपयोगकर्ता

      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 विकल्पों के बारे में, 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. लीफ़ सर्टिफ़िकेट:

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

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

      Messages प्रोसेसर (क्लाइंट) के ट्रस्टस्टोर से:

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

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

    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

      Messages प्रोसेसर (क्लाइंट) के ट्रस्टस्टोर से:

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

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

    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

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

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

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

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

रिज़ॉल्यूशन

  1. पक्का करें कि आपके पास बैकएंड सर्वर की पूरी और सही सर्टिफ़िकेट चेन हो.
  2. अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो सर्टिफ़िकेट को Apigee Edge के Message प्रोसेसर ट्रस्टस्टोर में अपडेट करने के लिए, Cloud के लिए TLS सर्टिफ़िकेट अपडेट करें में दिए गए निर्देशों का पालन करें.
  3. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो सर्टिफ़िकेट को Apigee Edge के Message प्रोसेसर ट्रस्टस्टोर में अपडेट करने के लिए, Private Cloud के लिए TLS सर्टिफ़िकेट अपडेट करें में दिए गए निर्देशों का पालन करें.

वजह: बैकएंड सर्वर के सर्टिफ़िकेट और टारगेट एंडपॉइंट में मौजूद होस्ट नेम, FQDN से मेल नहीं खाता

अगर बैकएंड सर्वर, सर्टिफ़िकेट की ऐसी चेन दिखाता है जिसमें FQDN शामिल है और जो टारगेट एंडपॉइंट में बताए गए होस्ट नेम से मेल नहीं खाता है, तो Apigee Edge की मैसेज प्रोसेस, गड़बड़ी 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 दिखाती है.

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

  1. एपीआई प्रॉक्सी में उस खास टारगेट एंडपॉइंट की जांच करें जिसमें इस गड़बड़ी को देखा जा रहा है. साथ ही, बैकएंड सर्वर के होस्ट नेम को नोट करें:

    सैंपल टारगेटएंडपॉइंट:

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

    ऊपर दिए गए उदाहरण में, बैकएंड सर्वर का होस्ट नाम backend.company.com है.

  2. नीचे दिखाए गए openssl कमांड का इस्तेमाल करके, बैकएंड सर्वर के सर्टिफ़िकेट में FQDN की पहचान करें:

    openssl s_client -connect BACKEND_SERVER_HOST_NAME>:PORT_#>

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

    openssl s_client -connect backend.company.com:443

    Certificate chain सेक्शन की जांच करें और लीफ़ सर्टिफ़िकेट के सब्जेक्ट में, CN के हिस्से के तौर पर बताए गए FQDN को नोट करें. 

    Certificate chain
 0 s:/CN=backend.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

    ऊपर दिए गए उदाहरण में, बैकएंड सर्वर का एफ़क्यूडीएन backend.apigee.net है.

  3. अगर पहले चरण से मिले बैकएंड सर्वर का होस्ट नेम और दूसरे चरण से मिला FQDN मैच नहीं करता, तो यही गड़बड़ी की वजह है.
  4. ऊपर दिए गए उदाहरण में, टारगेट एंडपॉइंट में होस्ट नेम backend.company.com है. हालांकि, बैकएंड सर्वर के सर्टिफ़िकेट में FQDN का नाम backend.apigee.net है. दोनों मेल नहीं खाते, इसलिए आपको यह गड़बड़ी मिली है.

रिज़ॉल्यूशन

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

सही FQDN

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

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

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

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

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

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

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

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

    ऊपर दिए गए उदाहरण में, अगर बैकएंड सर्वर के होस्ट का नाम गलत तरीके से बताया गया था, तो इसे ठीक करने के लिए बैकएंड सर्वर के सर्टिफ़िकेट से एफ़क्यूडीएन का इस्तेमाल करें. गड़बड़ी का पता 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>

वजह: बैकएंड सर्वर ने गलत/अधूरे सर्टिफ़िकेट या सर्टिफ़िकेट चेन उपलब्ध कराई है

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

  1. बैकएंड सर्वर के सर्टिफ़िकेट की चेन पाएं. इसके लिए, बैकएंड सर्वर के होस्ट नेम के लिए openssl कमांड को लागू करें. ऐसा करने के लिए, यह तरीका अपनाएं: 
    openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    ऊपर दिए गए निर्देश के आउटपुट से Certificate chain को नोट करें.

    openएसएसएल कमांड आउटपुट से सैंपल बैकएंड सर्वर सर्टिफ़िकेट चेन:

    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. पुष्टि करें कि आपके पास सही और पूरी सर्टिफ़िकेट चेन है, जैसा कि सर्टिफ़िकेट की पुष्टि करने की चेन में बताया गया है.

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

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

रिज़ॉल्यूशन

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

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

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

अगर समस्या अब भी बनी रहती है, तो गड़बड़ी की जानकारी इकट्ठा करनी होगी पर जाएं.

ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़ी जानकारी इकट्ठा करनी होगी

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

  • अगर आप सार्वजनिक क्लाउड का इस्तेमाल करते हैं, तो यह जानकारी दें:
    • संगठन का नाम
    • परिवेश का नाम
    • एपीआई प्रॉक्सी का नाम
    • गड़बड़ी को फिर से सामने लाने के लिए, curl निर्देश पूरा करें
    • गड़बड़ी दिखाने वाली ट्रेस फ़ाइल

    • openssl निर्देश का आउटपुट:

      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    • बैकएंड सर्वर पर कैप्चर किए गए टीसीपी/आईपी पैकेट
  • अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो यह जानकारी दें:

References