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

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

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

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

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

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

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"
      }
   }
}

संभावित कारण

आपको स्टेटस कोड 503 Service Unavailable और गड़बड़ी कोड messaging.adaptors.http.flow.SslHandshakeFailed मिल सकता है. ऐसा कई वजहों से हो सकता है. जैसे, Apigee Edge के मैसेज प्रोसेसर और बैकएंड सर्वर के बीच एसएसएल हैंडशेक की प्रोसेस पूरी न हो पाने की वजह से. गड़बड़ी के मैसेज में, 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 में गड़बड़ी का मैसेज faultstring दिखता है, तो इस गड़बड़ी को ठीक करने का तरीका जानें.

यह गड़बड़ी, Apigee Edge के मैसेज प्रोसेसर और बैकएंड सर्वर के बीच एसएसएल हैंडशेक प्रोसेस के दौरान होती है:

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

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

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

गड़बड़ी का पता लगाने के सामान्य चरण

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

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

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

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

  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

ट्रेस

दूसरी प्रक्रिया: Trace टूल का इस्तेमाल करना

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

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

  2. पक्का करें कि Show all 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 Data Recorded) फ़ेज़ पर जाएं और उस पर क्लिक करें.

  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

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

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

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

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

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

  3. खोजें कि क्या किसी खास समयावधि के दौरान, गड़बड़ी कोड 503messaging.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

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

चौथी प्रक्रिया: मैसेज प्रोसेसर के लॉग का इस्तेमाल करना

  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 का मैसेज प्रोसेसर, बैकएंड सर्वर के सर्टिफ़िकेट की पुष्टि नहीं कर सका.

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

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

  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. दूसरा चरण: Message Processor के ट्रस्टस्टोर में सेव की गई सर्टिफ़िकेट चेन की तुलना करना

पहला चरण

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

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

openssl

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

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

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

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

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. अगर आप Private Cloud के उपयोगकर्ता हैं, तो बैकएंड सर्वर या मैसेज प्रोसेसर पर टीसीपी/आईपी पैकेट कैप्चर किए जा सकते हैं. बेहतर होगा कि इन्हें बैकएंड सर्वर पर कैप्चर किया जाए, क्योंकि पैकेट बैकएंड सर्वर पर डिक्रिप्ट किए जाते हैं.

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

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

  4. Wireshark टूल या इसी तरह के किसी ऐसे टूल का इस्तेमाल करके टीसीपी/आईपी पैकेट का विश्लेषण करें जिसके बारे में आपको जानकारी हो.

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

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

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

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

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

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

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

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

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

दूसरा चरण

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

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

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

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

    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"

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

      आउटपुट का उदाहरण:

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

      [
  "serverCert"
]
    2. किसी कीस्टोर या ट्रस्टस्टोर से, किसी खास सर्टिफ़िकेट की जानकारी पाएं. यह एपीआई, किसी खास ट्रस्टस्टोर में मौजूद किसी खास सर्टिफ़िकेट के बारे में जानकारी देता है.

      पब्लिक क्लाउड का उपयोगकर्ता:

      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"

      Private 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 विकल्पों के बारे में, 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

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

      "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

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

      "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 Processor के ट्रस्टस्टोर में मौजूद नहीं है.

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

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

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

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

    <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. बैकएंड सर्वर के सर्टिफ़िकेट में मौजूद FQDN का पता लगाने के लिए, नीचे दी गई openssl कमांड का इस्तेमाल करें:

    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

    ऊपर दिए गए उदाहरण में, बैकएंड सर्वर का FQDN backend.apigee.net है.

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

रिज़ॉल्यूशन

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

सही एफ़क्यूडीएन

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

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

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

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

बैकएंड सर्वर सही होना चाहिए

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

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

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

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

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

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

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

    ऊपर दी गई कमांड के आउटपुट से Certificate chain नोट करें.

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

    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_#

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

रेफ़रंस