आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
इस पेज पर जाएं
Apigee X दस्तावेज़. जानकारी
समस्या का ब्यौरा
क्लाइंट ऐप्लिकेशन को "एसएसएल सर्टिफ़िकेट से जुड़ी गड़बड़ी" मैसेज. यह गड़बड़ी आम तौर पर Edge राऊटर से भेजी जाती है Apigee Edge से आने वाले कनेक्शन के लिए, TLS सेटअप को दो-तरफ़ा चालू किया गया है.
गड़बड़ी संदेश
क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:
HTTP/1.1 400 Bad Request
इसके बाद नीचे दिया गया एचटीएमएल गड़बड़ी वाला पेज दिखता है:
<html> <head> <title>400 The SSL certificate error</title> </head> <body bgcolor="white"> <center> <h1>400 Bad Request</h1> </center> <center>The SSL certificate error</center> <hr> <center>nginx</center> </body> </html>
संभावित वजहें
इस समस्या की ये वजहें हो सकती हैं:
Cause | जानकारी | समस्या हल करने के निर्देश इनके लिए लागू होते हैं |
क्लाइंट सर्टिफ़िकेट की समयसीमा खत्म हो चुकी है | क्लाइंट ने जो सर्टिफ़िकेट भेजा था उसकी समयसीमा खत्म हो गई है. | Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता |
क्लाइंट ने गलत सर्टिफ़िकेट भेजा है | क्लाइंट ऐप्लिकेशन से भेजा गया सर्टिफ़िकेट मेल न खाने पर यह गड़बड़ी होती है को एज के राऊटर के ट्रस्टस्टोर में सेव किया गया होगा. | Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता |
Truststore में क्लाइंट रूट सर्टिफ़िकेट मौजूद नहीं है | यह गड़बड़ी तब होती है, जब Edge के राऊटर का भरोसेमंद स्टोर है. | Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता |
Edge राऊटर में क्लाइंट सर्टिफ़िकेट लोड नहीं हुए | ट्रस्टस्टोर में अपलोड किए गए क्लाइंट सर्टिफ़िकेट लोड नहीं होने पर यह गड़बड़ी होती है ट्रैक कर रही हूँ. | Edge के प्राइवेट क्लाउड के उपयोगकर्ता |
वजह: क्लाइंट सर्टिफ़िकेट की समयसीमा खत्म हो गई है
यह समस्या आम तौर पर दो-तरफ़ा TLS के साथ होती है, जब क्लाइंट के भेजे गए सर्टिफ़िकेट की समयसीमा खत्म हो जाती है. 2-तरफ़ा TLS में, क्लाइंट और सर्वर दोनों का एक्सचेंज हैंडशेक पूरा करने के लिए अपने सार्वजनिक सर्टिफ़िकेट. क्लाइंट, सर्वर के सर्टिफ़िकेट की पुष्टि करता है और सर्वर क्लाइंट सर्टिफ़िकेट की पुष्टि करता है.
Edge में, वर्चुअल होस्ट पर दो-तरफ़ा TLS लागू किया जाता है, जहां कीस्टोर में सर्वर सर्टिफ़िकेट को और क्लाइंट सर्टिफ़िकेट को Truststores में जोड़ा जाता है.
TLS हैंडशेक के दौरान, अगर यह पता चलता है कि क्लाइंट सर्टिफ़िकेट की समयसीमा खत्म हो गई है, तो सर्वर इस पर "400 - गलत अनुरोध" मैसेज "एसएसएल सर्टिफ़िकेट से जुड़ी गड़बड़ी" के साथ भेजा जाएगा.
संक्रमण की जांच
Edge यूज़र इंटरफ़ेस (यूआई) में लॉग इन करें और खास वर्चुअल होस्ट कॉन्फ़िगरेशन देखें (एडमिन > वर्चुअल होस्ट) जिसके लिए एपीआई अनुरोध किया जा रहा है बनाया गया हो या वर्चुअल होस्ट एपीआई पाएं का इस्तेमाल करें मैनेजमेंट एपीआई का इस्तेमाल करें.
आम तौर पर, दो-तरफ़ा TLS बातचीत के लिए वर्चुअल होस्ट इस तरह दिखता है:
<VirtualHost name="myTLSVHost"> <HostAliases> <HostAlias>api.myCompany.com</HostAlias> </HostAliases> <Port>443</Port> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>true</ClientAuthEnabled> <KeyStore>ref://myKeystoreRef</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> <TrustStore>ref://myTruststoreRef</TrustStore> </SSLInfo> </VirtualHost>
वर्चुअल होस्ट में इस्तेमाल किया गया Truststore रेफ़रंस तय करें. ऊपर दिए गए उदाहरण में, Truststore का रेफ़रंस नेम myTruststoreRef है.
- पता लगाएं कि Truststore संदर्भ से जुड़ा Truststore क्या है.
- Edge यूज़र इंटरफ़ेस (यूआई) में एडमिन > एनवायरमेंट > रेफ़रंस और Truststore संदर्भ नाम खोजें.
खास Truststore संदर्भ के लिए रेफ़रंस कॉलम में नाम नोट करें. यह आपका Truststore नाम होगा.
ऊपर दिए गए उदाहरण में ध्यान दें कि myTruststoreRef में रेफ़रंस मौजूद है myTruststore के लिए. इसलिए, Truststore का नाम myTruststore है.
- एडमिन > एनवायरमेंट > Edge के यूज़र इंटरफ़ेस (यूआई) में TLS कीस्टोर की मदद से, TLS पर जाएं कीस्टोर पर जाएं और चरण # 3 में मिला Truststore ढूंढें.
नीचे दिए गए तरीके से, ऊपर दिए गए चरण #3 में बताए गए Truststore के तहत सर्टिफ़िकेट चुनें:
ऊपर दिए गए उदाहरण में उपनाम
client-cert-markw
वाला प्रमाणपत्र, दिखाता है कि यह समयसीमा खत्म हो गई है.- देखें कि आपके Truststore के सर्टिफ़िकेट उपनाम के लिए सर्टिफ़िकेट की समयसीमा खत्म तो नहीं हो गई है.
- अगर सर्टिफ़िकेट की समयसीमा खत्म नहीं हुई है, तो अन्य वजहों के लिए विश्लेषण करने के सामान्य तरीके पर जाएं.
रिज़ॉल्यूशन
एक नया प्रमाणपत्र बनाएं और प्रमाणपत्र अपलोड करें:
- एक नया ट्रस्टस्टोर बनाएं, जैसे कि myNewTruststore.
- नए सर्टिफ़िकेट को नए ट्रस्टस्टोर में अपलोड करें.
नए को पॉइंट करने के लिए, खास वर्चुअल होस्ट में इस्तेमाल किए गए ट्रुस्टोर रेफ़रंस में बदलाव करें में दिए गए चरणों का इस्तेमाल करके Truststore पहचान फ़ाइल में बदलाव करना.
ऊपर बताए गए उदाहरण में, myTruststoreRef को myNewTruststore पर ले जाएं.
अन्य वजहों को पहचानने के सामान्य तरीके
- इस समस्या की जांच करने के लिए, आपको
tcpdump टूल.
- अगर आप प्राइवेट क्लाउड के उपयोगकर्ता हैं, तो आपके पास क्लाइंट ऐप्लिकेशन या राऊटर से कनेक्ट हो.
- अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो क्लाइंट ऐप्लिकेशन पर टीसीपी/आईपी पैकेट कैप्चर करें.
एक बार आपने यह तय कर लिया कि आपको टीसीपी/आईपी पैकेट कहां से कैप्चर करने हैं, तो इन चीज़ों का इस्तेमाल करें: tcpdump टीसीपी/आईपी पैकेट कैप्चर करने के लिए निर्देश:
tcpdump -i any -s 0 host <IP address> -w <File name>
ध्यान दें: अगर राऊटर पर टीसीपी/आईपी पैकेट इस्तेमाल किए जा रहे हैं, तो
tcpdump
कमांड में क्लाइंट ऐप्लिकेशन का सार्वजनिक आईपी पता.अगर क्लाइंट ऐप्लिकेशन पर टीसीपी/आईपी पैकेट इस्तेमाल किए जा रहे हैं, तो सार्वजनिक आईपी का इस्तेमाल करें
tcpdump
कमांड में वर्चुअल होस्ट में इस्तेमाल किए गए होस्ट के नाम का पता.tcpdump देखें कृपया इस टूल और इस निर्देश के अन्य वैरिएंट के बारे में ज़्यादा जानकारी देखें.
- इसका इस्तेमाल करके इकट्ठा किए गए टीसीपी/आईपी पैकेट का विश्लेषण करें Wireshark टूल या इससे मिलता-जुलता टूल, जिसके बारे में आपको पूरी जानकारी है.
यहां Wireshark टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट के सैंपल डेटा का विश्लेषण किया गया है:
- tcpdump (नीचे दी गई इमेज) में पैकेट #30 से पता चलता है कि क्लाइंट ऐप्लिकेशन (सोर्स) "क्लाइंट को नमस्ते" भेजा है राऊटर (डेस्टिनेशन) को मैसेज भेजने का विकल्प.
- पैकेट #34 दिखाता है कि राऊटर, क्लाइंट ऐप्लिकेशन से मिलने वाले क्लाइंट को नमस्ते मैसेज की पुष्टि करता है.
- राऊटर "सर्वर नमस्ते" भेजता है पैकेट #35 में शामिल करता है और फिर अपना सर्टिफ़िकेट और क्लाइंट ऐप्लिकेशन को पैकेट #38 में अपना सर्टिफ़िकेट भेजने का अनुरोध करता है.
- पैकेट #38 में, जहां राऊटर "सर्टिफ़िकेट का अनुरोध" पैकेट भेजता है, वहां "जाने-पहचाने नाम" सेक्शन, जिसमें क्लाइंट सर्टिफ़िकेट और उसकी चेन के बारे में जानकारी दी गई है और वे सर्टिफ़िकेट अथॉरिटी हैं जिन्हें राऊटर (सर्वर) स्वीकार करता है.
क्लाइंट ऐप्लिकेशन, पैकेट # 41 में अपना सर्टिफ़िकेट भेजता है. सर्टिफ़िकेट देखें पैकेट # 41 में सेक्शन की पुष्टि करें और क्लाइंट ऐप्लिकेशन से भेजे गए सर्टिफ़िकेट का पता लगाएं.
- पुष्टि करें कि सर्टिफ़िकेट जारी करने वाली कंपनी और सर्टिफ़िकेट देने वाले व्यक्ति या कंपनी और उसकी चेन की जानकारी, क्लाइंट ने भेजी है ऐप्लिकेशन (पैकेट #41), राऊटर के स्वीकार किए गए सर्टिफ़िकेट और उसकी चेन से मेल खाता है (पैकेट #38). अगर कुछ मैच नहीं होता है, तो इस गड़बड़ी की वजह यही होगी. यही वजह है राऊटर (सर्वर) एन्क्रिप्ट (सुरक्षित) की गई सूचना (पैकेट #57) के बाद FIN, ACK (पैकेट 58) क्लाइंट ऐप्लिकेशन इंस्टॉल किया जाता है और फिर कनेक्शन बंद कर दिया जाता है.
- सर्टिफ़िकेट और उसकी चेन के मेल न खाने की वजह यहां दी गई स्थितियां हो सकती हैं सेक्शन पढ़ें.
वजह: क्लाइंट ने गलत सर्टिफ़िकेट भेजा है
आम तौर पर, ऐसा तब होता है, जब सर्टिफ़िकेट और/या उसकी चेन को जारी करने वाला व्यक्ति या कंपनी क्लाइंट ऐप्लिकेशन, राऊटर (सर्वर) के ट्रस्टस्टोर में स्टोर किए गए सर्टिफ़िकेट और/या उसकी चेन से मेल नहीं खाता.
संक्रमण की जांच
Edge यूज़र इंटरफ़ेस (यूआई) में साइन इन करें और खास वर्चुअल होस्ट कॉन्फ़िगरेशन देखें (एडमिन > वर्चुअल होस्ट) जिसके लिए एपीआई अनुरोध किया जा रहा है बनाया गया हो या वर्चुअल होस्ट एपीआई पाएं का इस्तेमाल करें मैनेजमेंट एपीआई का इस्तेमाल करें.
आम तौर पर, दो-तरफ़ा TLS बातचीत के लिए वर्चुअल होस्ट इस तरह दिखता है:
<VirtualHost name="myTLSVHost"> <HostAliases> <HostAlias>api.myCompany.com</HostAlias> </HostAliases> <Port>443</Port> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>true</ClientAuthEnabled> <KeyStore>ref://myKeystoreRef</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> <TrustStore>ref://myCompanyTruststoreRef</TrustStore> </SSLInfo> </VirtualHost>
- वर्चुअल होस्ट में इस्तेमाल किया गया Truststore रेफ़रंस तय करें.
ऊपर दिए गए उदाहरण में, Truststore रेफ़रंस का नाम myCompanyTruststoreRef है.
- Truststore संदर्भ की मदद से दिखाया गया Truststore पता लगाएं.
- Edge यूज़र इंटरफ़ेस (यूआई) में एडमिन > एनवायरमेंट रेफ़रंस और Truststore संदर्भ नाम खोजें.
खास Truststore संदर्भ के लिए रेफ़रंस कॉलम में नाम नोट करें. यह आपका Truststore नाम होगा.
ऊपर दिए गए उदाहरण में, ध्यान दें कि myCompanyTruststoreRef के पास का संदर्भ दें. इसलिए, Truststore का नाम myCompanyTruststore है.
- नीचे दिए गए एपीआई का इस्तेमाल करके, Truststore (पिछले चरण में तय किया गया) में सेव किए गए सर्टिफ़िकेट पाएं:
कीस्टोर या Truststore API के लिए सर्टिफ़िकेट की सूची बनाएं.
यह एपीआई खास Truststore के सभी सर्टिफ़िकेट की सूची बनाता है.
कीस्टोर या Truststore API से सर्टिफ़िकेट की जानकारी पाएं.
यह एपीआई, Truststore में मौजूद किसी खास सर्टिफ़िकेट की जानकारी दिखाता है.
- देखें कि हर सर्टिफ़िकेट को जारी करने वाला बैंक या कंपनी और उसकी चेन, यहां सेव है या नहीं myCompanyTruststore सर्टिफ़िकेट और इसकी चेन से मेल खाता है ऊपर दिए गए टीसीपी/आईपी पैकेट (पैकेट #38 देखें) में दिए गए हैं. अगर कुछ मैच नहीं होता है, तो यह दिखता है कि Truststore में अपलोड किए गए सर्टिफ़िकेट एज राऊटर में लोड नहीं हो रहे हैं. वजह: Edge राऊटर में क्लाइंट सर्टिफ़िकेट लोड नहीं है पर जाएं.
- अगर चरण #5 में कोई भी मेल नहीं खाता, तो इसका मतलब है कि क्लाइंट ऐप्लिकेशन ने सही प्रमाणपत्र और उसकी शृंखला न भेजें.
रिज़ॉल्यूशन
पक्का करें कि क्लाइंट ऐप्लिकेशन, Edge को सही सर्टिफ़िकेट और उसकी चेन भेजे.
वजह: Truststore में क्लाइंट रूट सर्टिफ़िकेट मौजूद नहीं है
यह गड़बड़ी तब होती है, जब Edge के राऊटर का भरोसेमंद स्टोर है.
संक्रमण की जांच
Edge के यूज़र इंटरफ़ेस (यूआई) में साइन इन करें. इसके बाद, वह वर्चुअल होस्ट कॉन्फ़िगरेशन देखें जिसके लिए एपीआई अनुरोध किया जा रहा है (एडमिन > वर्चुअल होस्ट > virtual_host), या इसका इस्तेमाल करें किसी खास वर्चुअल होस्ट की परिभाषा जानने के लिए, वर्चुअल होस्ट एपीआई पाएं.
आम तौर पर, दो-तरफ़ा TLS बातचीत के लिए वर्चुअल होस्ट इस तरह दिखता है:
<VirtualHost name="myTLSVHost"> <HostAliases> <HostAlias>api.myCompany.com</HostAlias> </HostAliases> <Port>443</Port> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>true</ClientAuthEnabled> <KeyStore>ref://myKeystoreRef</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> <TrustStore>ref://myCompanyTruststoreRef</TrustStore> </SSLInfo> </VirtualHost>
- वर्चुअल होस्ट में इस्तेमाल किया गया Truststore रेफ़रंस तय करें. पिछले उदाहरण में, Truststore का रेफ़रंस नाम myCompanyTruststoreRef है.
- उस असली Truststore का पता लगाएं जिसे Truststore संदर्भ के लिए इस्तेमाल किया जा रहा है.
- Edge यूज़र इंटरफ़ेस (यूआई) में, एडमिन > एनवायरमेंट > रेफ़रंस और उसे खोजना डालें.
खास Truststore संदर्भ के लिए Truststore का नाम रेफ़रंस कॉलम.
इस उदाहरण में, ध्यान दें कि myCompanyTruststoreRef ने myCompanyTruststore को भी जोड़ा जा सकता है. इसलिए, Truststore नाम myCompanyTruststore है.
- इसका इस्तेमाल करके ट्रस्टस्टोर (पिछले चरण में तय किया गया) में सेव किए गए सर्टिफ़िकेट पाएं
नीचे दिए गए एपीआई:
- कीस्टोर या Truststore API के लिए सर्टिफ़िकेट की सूची बनाएं. इस एपीआई में सभी सर्टिफ़िकेट.
- कीस्टोर या Truststore API से सर्टिफ़िकेट की जानकारी पाएं. यह एपीआई, Truststore में एक खास सर्टिफ़िकेट.
यह देखें कि सर्टिफ़िकेट में रूट सर्टिफ़िकेट के साथ-साथ पूरी चेन शामिल है या नहीं किसी क्लाइंट की ओर से भेजा गया, जैसा कि टीसीपी/आईपी पैकेट में दिखाया गया है (इमेज 4 देखें). ट्रस्टस्टोर इसमें रूट सर्टिफ़िकेट और क्लाइंट का लीफ़ सर्टिफ़िकेट या लीफ़ सर्टिफ़िकेट शामिल होना चाहिए और इंटरमीडिएट सर्टिफ़िकेट. अगर Truststore में क्लाइंट का मान्य रूट सर्टिफ़िकेट मौजूद नहीं है, यही गड़बड़ी की वजह है.
हालांकि, अगर क्लाइंट का रूट सर्टिफ़िकेट के साथ-साथ सर्टिफ़िकेट की पूरी चेन, में मौजूद है, तो यह बताता है कि शायद Edge राऊटर में Truststore लोड न हो. अगर ऐसा है, तो वजह: Edge राऊटर में क्लाइंट सर्टिफ़िकेट लोड नहीं हैं.
रिज़ॉल्यूशन
पक्का करें कि रूट सर्टिफ़िकेट के साथ-साथ सही क्लाइंट का सर्टिफ़िकेट उपलब्ध हो के भरोसेमंद सोर्स में से एक है.
वजह: Edge राऊटर में क्लाइंट सर्टिफ़िकेट लोड नहीं हैं
- अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो Apigee Edge की सहायता टीम से संपर्क करें.
- अगर आप प्राइवेट Cloud उपयोगकर्ता हैं, तो हर राऊटर के लिए नीचे दिए गए निर्देशों का पालन करें:
- देखें कि
/opt/nginx/conf.d/OrgName_envName_vhostName-client.pem
फ़ाइल मौजूद है या नहीं खास वर्चुअल होस्ट के लिए. अगर फ़ाइल मौजूद नहीं है, तो इस पर ले जाएं रिज़ॉल्यूशन सेक्शन देखें. - अगर फ़ाइल मौजूद है, तो फ़ाइल की जानकारी पाने के लिए, नीचे दिए गए
openssl
कमांड का इस्तेमाल करें Edge राऊटर पर उपलब्ध सर्टिफ़िकेट:openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
- सर्टिफ़िकेट जारी करने वाले बैंक/कंपनी, विषय, और सर्टिफ़िकेट की समयसीमा खत्म होने की तारीख देखें. अगर इनमें से कोई भी मैच नहीं होता जो Edge के यूज़र इंटरफ़ेस (यूआई) में Truststore में देखा गया था या मैनेजमेंट एपीआई का इस्तेमाल किया गया था, तो गड़बड़ी की वजह है.
- ऐसा हो सकता है कि राऊटर ने अपलोड किए गए सर्टिफ़िकेट फिर से लोड न किए हों.
- देखें कि
रिज़ॉल्यूशन
राऊटर को रीस्टार्ट करें, ताकि यह पक्का किया जा सके कि नीचे दिए गए तरीके से नए सर्टिफ़िकेट लोड हो गए हैं:
apigee-service edge-router restart
एपीआई फिर से चलाएं और नतीजों की जांच करें. अगर समस्या बनी रहती है, तो यहां जाएं गड़बड़ी की जानकारी इकट्ठा करें.
गड़बड़ी की जानकारी इकट्ठा करें
अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो कृपया गड़बड़ी की यह जानकारी इकट्ठा करें. इकट्ठा की गई जानकारी को Apigee Edge की सहायता टीम से संपर्क करें और शेयर करें:
- अगर आप Public Cloud उपयोगकर्ता हैं, तो यह जानकारी दें:
- संगठन का नाम
- एनवायरमेंट का नाम
- एपीआई प्रॉक्सी का नाम
- वर्चुअल होस्ट का नाम
- होस्ट का उपनाम नाम
- गड़बड़ी को ठीक करने के लिए curl कमांड पूरा करें
- क्लाइंट ऐप्लिकेशन पर कैप्चर किए गए टीसीपी/आईपी पैकेट
- अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो यह जानकारी दें:
- वर्चुअल होस्ट एपीआई पाएं का इस्तेमाल करके, वर्चुअल होस्ट का नाम और उसकी परिभाषा
- होस्ट का उपनाम नाम
- पूरा गड़बड़ी का मैसेज दिखा
- क्लाइंट ऐप्लिकेशन या राऊटर पर कैप्चर किए गए टीसीपी/आईपी पैकेट.
- keystore API से सर्टिफ़िकेट की सूची बनाएं का आउटपुट एपीआई और सर्टिफ़िकेट की जानकारी वाले एपीआई का इस्तेमाल करके मिले हर सर्टिफ़िकेट की जानकारी भी शेयर की जाती है.
- इस प्लेबुक में दिखाए जाने वाले सेक्शन के बारे में जानकारी और ऐसी अन्य अहम जानकारी जो इस समस्या को तेज़ी से हल करने में हमारी मदद करेंगे.