TLS सर्टिफिकेट वैलिडेशन कैसे काम करता है, और आप विफलताओं को कैसे डीबग करते हैं?

प्रश्न और लागू संदर्भ

api.example.com द्वारा अपने TLS सर्टिफिकेट को रोटेट करने के बाद, ब्राउज़र और एक सामान्य curl https://api.example.com अनुरोध सफल हो जाते हैं। कस्टम ट्रस्टस्टोर का उपयोग करने वाला एक Java 21 वर्कर SunCertPathBuilderException: unable to find valid certification path के साथ विफल हो जाता है। इस बीच, curl https://203.0.113.10 उसी लोड बैलेंसर तक पहुंचता है लेकिन आइडेंटिटी वेरिफिकेशन में विफल हो जाता है।

बताएं कि एक TLS क्लाइंट सर्टिफिकेट पाथ को कैसे बनाता और वैलिडेट करता है, यह लक्षित सर्विस आइडेंटिटी से कैसे मेल खाता है, ये क्लाइंट अलग-अलग परिणामों तक क्यों पहुंच सकते हैं, और आप सर्टिफिकेट या होस्टनेम वेरिफिकेशन को डिसेबल किए बिना इस घटना का डायग्नोसिस और समाधान कैसे करेंगे।

इन स्पष्ट मान्यताओं का उपयोग करें: api.example.com और 203.0.113.10 काल्पनिक हैं; एंडपॉइंट एक सामान्य सार्वजनिक रूप से विश्वसनीय (publicly trusted) सर्वर सर्टिफिकेट का उपयोग करता है; Java वर्कर का कस्टम ट्रस्टस्टोर ब्राउज़र के ट्रस्ट कॉन्फ़िगरेशन से स्वतंत्र है; और लोड बैलेंसर एक ही IP एड्रेस पर कई TLS नाम होस्ट कर सकता है। यह कार्य सर्टिफिकेट प्रमाणीकरण (authentication) और परिचालन डायग्नोसिस (operational diagnosis) से संबंधित है। साइफर-सूट नेगोशिएशन (Cipher-suite negotiation), TLS 1.3 की-शेड्यूल (key schedule), और 0-RTT मुख्य दायरे से बाहर हैं।

यह प्रश्न सामान्य सॉफ्टवेयर इंजीनियरिंग, नेटवर्किंग, SRE, प्लेटफॉर्म, सुरक्षा, बैकएंड और क्लाइंट इंटरव्यू के लिए उपयुक्त है। एक उपयोगी उत्तर केवल "लीफ (leaf), इंटरमीडिएट (intermediate), रूट (root)" रटने के बजाय PKI नियमों को अवलोकन योग्य क्लाइंट व्यवहार से जोड़ेगा।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला, क्या उम्मीदवार उन चार निर्णयों को अलग कर सकता है जिन्हें अक्सर एक मान लिया जाता है?

1. पाथ निर्माण (Path construction): लीफ से शून्य या अधिक इंटरमीडिएट्स के माध्यम से स्थानीय रूप से कॉन्फ़िगर किए गए ट्रस्ट एंकर तक एक संभावित अनुक्रम (candidate sequence) खोजना।
2. पाथ वैलिडेशन (Path validation): सत्यापित करना कि संभावित पाथ सिग्नेचर, समय, CA कंस्ट्रेंट्स, की (key) उपयोग, नाम कंस्ट्रेंट्स, क्रिटिकल एक्सटेंशन, एल्गोरिदम और पॉलिसी आवश्यकताओं, और लक्षित TLS सर्वर उद्देश्य को पूरा करता है।
3. सर्विस-आइडेंटिटी मैचिंग: कॉन्फ़िगर किए गए संदर्भ होस्टनेम या IP एड्रेस का संबंधित subjectAltName पहचानकर्ता से मिलान करना।
4. हैंडशेक प्रूफ: CertificateVerify को सत्यापित करना ताकि पीयर लीफ सर्टिफिकेट की प्राइवेट की (private key) के स्वामित्व को साबित कर सके और इसे इस हैंडशेक से बाइंड कर सके।

दूसरा, क्या उम्मीदवार किसी सार्वभौमिक कारण का आविष्कार किए बिना क्लाइंट्स के बीच अंतर को समझा सकता है? ब्राउज़र, ऑपरेटिंग सिस्टम टूल्स, कंटेनर, JVMs, मोबाइल ऐप्स, और कॉर्पोरेट प्रॉक्सी विभिन्न ट्रस्ट एंकर, कैश्ड या खोजने योग्य इंटरमीडिएट्स, घड़ियां, एल्गोरिदम, निरस्तीकरण (revocation) नीतियां, और संदर्भ आइडेंटिटीज का उपयोग कर सकते हैं।

तीसरा, क्या उम्मीदवार एक नियंत्रित जांच चला सकता है? एक मजबूत उत्तर सही SNI के साथ डिलीवर की गई सटीक सर्टिफिकेट चेन को कैप्चर करता है, विफल क्लाइंट के ट्रस्ट मटीरियल के साथ वैलिडेशन को पुन: उत्पन्न (reproduce) करता है, IP पिन करते समय होस्टनेम को बनाए रखता है, सफल और विफल पाथ्स की तुलना करता है, और प्रत्येक लोड-बैलेंसर इंस्टेंस की जांच करता है।

अंत में, क्या उम्मीदवार ट्रस्ट को सुरक्षित रूप से रीस्टोर कर सकता है? किसी मनमाने लीफ को इम्पोर्ट करना, सभी सर्टिफिकेट्स को स्वीकार करना, होस्टनेम जांच को छोड़ना, या curl -k का उपयोग करना केवल विफल सुरक्षा नियंत्रण को छुपाता है। समाधान को लक्षित चेन या ट्रस्ट पॉलिसी को रीस्टोर करना चाहिए और इसमें किसी भी अस्थायी ट्रस्ट परिवर्तन के लिए रोलबैक और एक्सपायरी योजना शामिल होनी चाहिए।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• प्रत्येक क्लाइंट किस सटीक URL और संदर्भ आइडेंटिटी का उपयोग करता है? किसी IP लिटरल से कनेक्ट करना एक IP आइडेंटिटी की मांग करता है। URL https://api.example.com को बनाए रखते हुए उसी IP से कनेक्ट करना DNS आइडेंटिटी api.example.com की मांग करता है।
• रनटाइम पर कौन सा ट्रस्ट स्टोर सक्रिय है? डेवलपर लैपटॉप के डिफ़ॉल्ट स्टोर का निरीक्षण करने के बजाय वास्तविक JVM ऑप्शन्स, कंटेनर इमेज, यूजर, प्रोसेस एनवायरनमेंट, और माउंटेड ट्रस्टस्टोर की पुष्टि करें।
• विफल अनुरोध को कौन सी चेन प्राप्त हुई? SNI, लोड-बैलेंसर लिसनर, क्षेत्र (region), प्रॉक्सी, IPv4 बनाम IPv6, और डिप्लॉयमेंट विषमता (skew) प्रस्तुत किए गए सर्टिफिकेट को बदल सकते हैं।
• क्या प्रत्येक क्लाइंट एक ही समय में विफल हुआ? स्थानीय समय, सर्टिफिकेट की वैधता, CA-बंडल वर्ज़न, एल्गोरिदम पॉलिसी, और क्या केवल एक बैकएंड या एज इंस्टेंस नई चेन सर्व करता है, इसकी जांच करें।
• क्या TLS इंटरसेप्टेड है? एक कॉर्पोरेट प्रॉक्सी सार्वजनिक लीफ को एक एंटरप्राइज रूट द्वारा जारी किए गए सर्टिफिकेट से बदल सकती है जिस पर एक ब्राउज़र भरोसा करता है लेकिन कस्टम JVM ट्रस्टस्टोर नहीं करता।
• त्रुटि क्या पहचानती है? पाथ-बिल्डिंग त्रुटि, समाप्त (expired) सर्टिफिकेट, होस्टनेम बेमेल (mismatch), असमर्थित एल्गोरिदम, निरस्तीकरण विफलता, और TLS नेगोशिएशन विफलता अलग-अलग शाखाएं हैं। पूर्ण एक्सेप्शन और वैलिडेशन ट्रेस को सुरक्षित रखें।

30-सेकंड का उत्तर ढांचा (Framework)

"मैं इस जांच को पाथ निर्माण, पाथ वैलिडेशन, सर्विस-आइडेंटिटी मैचिंग, और प्राइवेट-की प्रूफ में विभाजित करता हूं। सर्वर सामान्यतः अपनी लीफ और आवश्यक इंटरमीडिएट्स भेजता है; क्लाइंट स्थानीय रूप से पहले से विश्वसनीय ट्रस्ट एंकर तक एक पाथ बनाता है। फिर यह सिग्नेचर, समय, CA और की कंस्ट्रेंट्स, क्रिटिकल एक्सटेंशन, एल्गोरिदम और सर्वर उद्देश्य को वैलिडेट करता है। अलग से, यह कॉन्फ़िगर किए गए DNS नाम या IP एड्रेस का उसी प्रकार की SAN एंट्री से मिलान करता है। SNI सर्वर को एक सर्टिफिकेट चुनने में मदद करता है, लेकिन यह ट्रस्ट स्थापित नहीं करता है और न ही होस्टनेम साबित करता है।

ब्राउज़र की सफलता यह साबित नहीं करती कि Java पाथ मान्य है क्योंकि कस्टम JVM ट्रस्टस्टोर, इंटरमीडिएट खोज, प्रॉक्सी रूट्स, घड़ी, और नीतियां भिन्न हो सकती हैं। मैं सही SNI के साथ चेन को कैप्चर करूंगा, इसे वर्कर के सटीक ट्रस्टस्टोर के विरुद्ध रीप्ले करूंगा, निर्मित पाथ्स की तुलना करूंगा, और IP को लक्षित करते हुए DNS आइडेंटिटी को स्थिर रखने के लिए curl --resolve का उपयोग करूंगा। मैं सर्व किए गए इंटरमीडिएट या जानबूझकर प्रबंधित ट्रस्ट एंकर को ठीक करूंगा, कभी भी वेरिफिकेशन को डिसेबल नहीं करूंगा, और प्रत्येक एज के साथ-साथ वास्तविक वर्कर का फिर से परीक्षण करूंगा।"

चरण-दर-चरण गहन विश्लेषण

1. तीन स्वतंत्र इनपुट्स स्थापित करें। सत्यापनकर्ता (verifier) को एक लक्षित लीफ सर्टिफिकेट, अविश्वसनीय (untrusted) इंटरमीडिएट सर्टिफिकेट्स का एक सेट जो पाथ बनाने में मदद कर सकता है, और एक या अधिक स्थानीय ट्रस्ट एंकर की आवश्यकता होती है। यहाँ "अविश्वसनीय" का अर्थ दुर्भावनापूर्ण नहीं है; इसका अर्थ है कि एक इंटरमीडिएट पाथ-निर्माण सामग्री है और केवल इसलिए ट्रस्ट एंकर नहीं बन जाता क्योंकि सर्वर ने इसे भेजा है।

एक HTTPS सर्वर आमतौर पर लीफ सर्टिफिकेट और उसके बाद क्लाइंट द्वारा आवश्यक इंटरमीडिएट्स भेजता है। आम तौर पर इसे रूट भेजने की आवश्यकता नहीं होती है। सत्यापनकर्ता का ट्रस्ट निर्णय स्थानीय नीति द्वारा कॉन्फ़िगर किए गए रूट या अन्य एंकर पर समाप्त होता है। रूट भेजने से कोई अज्ञात रूट विश्वसनीय नहीं बन सकता।

2. किसी एक को वैलिडेट करने से पहले संभावित पाथ्स का निर्माण करें। लीफ एक जारीकर्ता (issuer) का नाम देती है; एक इंटरमीडिएट दूसरे जारीकर्ता का नाम दे सकता है; क्रॉस-हस्ताक्षरित (cross-signed) CAs एक से अधिक संभावित मार्ग बना सकते हैं। एक क्लाइंट हैंडशेक, कैश, या कार्यान्वयन-विशिष्ट खोज तंत्र से इंटरमीडिएट्स प्राप्त कर सकता है। RFC 5280 पाथ वैलिडेशन को परिभाषित करता है लेकिन संभावित अनुक्रम प्राप्त करने की प्रक्रिया को जानबूझकर अपने दायरे से बाहर रखता है। इसलिए दो मानक-अनुरूप क्लाइंट्स के पास अलग-अलग निर्माण इनपुट हो सकते हैं और वे अलग-अलग पाथ चुन सकते हैं।

SunCertPathBuilderException का अर्थ है कि Java पाथ बिल्डर को कोई ऐसा पाथ नहीं मिला जिसे वह अपने उपलब्ध सर्टिफिकेट्स और पॉलिसी के साथ स्वीकार कर सके। संभावित कारणों में एक अनुपलब्ध इंटरमीडिएट, कस्टम स्टोर में ट्रस्ट एंकर का न होना, एक अनुपयोगी वैकल्पिक पाथ, या एक पॉलिसी कंस्ट्रेंट शामिल हैं। केवल एक्सेप्शन यह साबित नहीं करता कि इनमें से कौन सा हुआ।

3. चयनित पाथ को वैलिडेट करें। प्रत्येक प्रासंगिक लिंक के लिए, क्लाइंट जारीकर्ता की पब्लिक की (public key) के साथ सर्टिफिकेट सिग्नेचर को सत्यापित करता है और बाधाओं (constraints) को प्रोसेस करता है। महत्वपूर्ण जांचों में शामिल हैं:

• वर्तमान समय सर्टिफिकेट के वैधता अंतराल (validity interval) के भीतर आता है;
• प्रत्येक जारीकर्ता सर्टिफिकेट को basicConstraints के तहत CA के रूप में कार्य करने की अनुमति है, और किसी भी पाथ-लंबाई सीमा का सम्मान किया जाता है;
• CA की उपयोग सर्टिफिकेट साइनिंग की अनुमति देता है, जबकि लीफ लागू की-उपयोग और विस्तारित-की-उपयोग नीति के तहत लक्षित TLS सर्वर उद्देश्य के लिए उपयुक्त है;
• नाम कंस्ट्रेंट्स, सर्टिफिकेट नीतियां, और मान्यता प्राप्त क्रिटिकल एक्सटेंशन सही ढंग से संसाधित होते हैं;
• एल्गोरिदम और की की ताकत क्लाइंट की वर्तमान सुरक्षा नीति को पूरा करती है; और
• पाथ स्थानीय नीति द्वारा चयनित ट्रस्ट एंकर पर समाप्त होता है।

निरस्तीकरण (Revocation) एक अन्य नीति आयाम है। क्लाइंट CRLs, OCSP प्रतिक्रियाओं, स्टेपल्ड स्टेटस, नेटवर्क त्रुटियों, और सॉफ्ट-फेल बनाम हार्ड-फेल स्थितियों को कैसे प्राप्त और संभालते हैं, इसमें भिन्नता होती है। यह न मानें कि "RFC 5280 पाथ वैलिडेशन पास हो गया" यह साबित करता है कि प्रत्येक क्लाइंट ने समान ऑनलाइन निरस्तीकरण जांच की थी।

4. सर्विस आइडेंटिटी का अलग से मिलान करें। संदर्भ आइडेंटिटी एक विश्वसनीय इनपुट से आती है जैसे कि कॉन्फ़िगर किया गया HTTPS URL, न कि रिवर्स DNS, सर्टिफिकेट से, या हमलावर द्वारा प्रदान किए गए किसी भी नाम से। RFC 9525 के तहत, आधुनिक सर्विस आइडेंटिटी को subjectAltName में दर्शाया जाता है; क्लाइंट्स को इस उद्देश्य के लिए सब्जेक्ट कॉमन नेम (Common Name) पर निर्भर नहीं होना चाहिए।

DNS नाम और IP एड्रेस विभिन्न SAN प्रकारों का उपयोग करते हैं। https://api.example.com के लिए एक मिलान DNS-ID की आवश्यकता होती है। https://203.0.113.10 के लिए iPAddress SAN में सटीक IP एड्रेस की आवश्यकता होती है; api.example.com युक्त एक DNS SAN इसे संतुष्ट नहीं करता है। यदि समर्थित हो, तो एक वाइल्डकार्ड पूरी तरह से सबसे बाईं ओर का लेबल होना चाहिए और ठीक एक लेबल से मेल खाता है: *.example.com, api.example.com से मेल खा सकता है, लेकिन v2.api.example.com या example.com से नहीं।

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

5. लीफ प्राइवेट की के स्वामित्व को सत्यापित करें। एक मान्य पाथ और मेल खाने वाला SAN एक आइडेंटिटी को एक पब्लिक की से बांधता है। सर्टिफिकेट-प्रमाणित TLS 1.3 हैंडशेक के दौरान, CertificateVerify संबंधित प्राइवेट की के साथ हैंडशेक ट्रांसक्रिप्ट पर हस्ताक्षर करता है। इसे सत्यापित करने से साबित होता है कि पीयर इस नेगोशिएशन में उस प्राइवेट की को नियंत्रित करता है। यह पाथ बनाने और होस्टनेम का मिलान करने से अलग है।

6. बताएं कि तीनों अवलोकन संगत क्यों हैं। अवलोकन एक दूसरे का खंडन नहीं करते हैं:

7. एंडपॉइंट और पाथ को स्वतंत्र रूप से पुन: उत्पन्न करें। सटीक DNS नाम और SNI के साथ शुरुआत करें। निम्नलिखित फ़्लैग OpenSSL 3.6 को लक्षित करते हैं; पहले openssl version की जांच करें क्योंकि macOS सिस्टम LibreSSL और पुराने पैकेज अलग-अलग विकल्प प्रदर्शित करते हैं। -showcerts प्रदर्शित करता है कि सर्वर ने क्या भेजा; -verify_return_error वैलिडेशन त्रुटियों पर रुकता है; -verify_hostname इच्छित DNS आइडेंटिटी की जांच करता है।

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -showcerts \
  -verify_return_error \
  -verify_hostname api.example.com \
  </dev/null

लीफ और इंटरमीडिएट सर्टिफिकेट्स को अलग-अलग PEM फ़ाइलों के रूप में सहेजें, विफल वातावरण से एक अनुमोदित निर्यात के माध्यम से सटीक विश्वसनीय रूट्स प्राप्त करें, और पाथ वैलिडेशन को स्पष्ट रूप से रीप्ले करें:

openssl verify \
  -CAfile worker-roots.pem \
  -untrusted served-intermediates.pem \
  -purpose sslserver \
  -verify_hostname api.example.com \
  leaf.pem

यह प्रयोग ट्रस्ट एंकर को इंटरमीडिएट्स से अलग करता है। यह प्रत्येक JVM एल्गोरिदम, निरस्तीकरण, या प्रदाता नियम का पूरी तरह से अनुकरण नहीं करता है, इसलिए निर्णायक रिप्रोडक्शन अभी भी ट्रस्ट-मैनेजर डिबग आउटपुट और उसी ट्रस्टस्टोर के साथ उसी Java इमेज के अंदर चलता है। लॉग साझा करने से पहले आंतरिक नामों और सर्टिफिकेट मटीरियल को छिपाएं (redact करें)।

HTTPS संदर्भ नाम को बदले बिना किसी विशिष्ट लोड-बैलेंसर एड्रेस को लक्षित करने के लिए, URL को बनाए रखें और रिज़ॉल्यूशन को ओवरराइड करें:

curl --resolve api.example.com:443:203.0.113.10 \
  https://api.example.com/health

प्रत्येक विज्ञापित IPv4 और IPv6 पते, क्षेत्र और एज इंस्टेंस के लिए दोहराएं। सीधे https://203.0.113.10 का अनुरोध करना एक अलग आइडेंटिटी टेस्ट है और इसका उपयोग इस प्रमाण के रूप में नहीं किया जाना चाहिए कि api.example.com के लिए सर्टिफिकेट गलत है।

8. विफल लेयर को ठीक करें और रोलबैक पाथ साबित करें। यदि सर्वर एक आवश्यक इंटरमीडिएट को छोड़ देता है, तो प्रत्येक TLS टर्मिनेटर पर सही लीफ-प्लस-इंटरमीडिएट बंडल को डिप्लॉय करें और सर्व की गई चेन की पुष्टि करें। यदि संगठन जानबूझकर एक निजी या प्रॉक्सी CA का उपयोग करता है, तो स्वामित्व, कार्यक्षेत्र (scope), फ़िंगरप्रिंट, समाप्ति (expiry), और रोलबैक दर्ज करके प्रबंधित ट्रस्टस्टोर प्रक्रिया के माध्यम से इसके अनुमोदित रूट को वितरित करें। यदि गलत SAN जारी किया गया था, तो सर्टिफिकेट को बदलें। यदि घड़ियां, पुराने इंस्टेंस, या एल्गोरिदम नीतियां भिन्न हैं, तो उन स्थितियों को सीधे ठीक करें।

एंडपॉइंट लीफ को स्थायी रूट के रूप में इम्पोर्ट न करें, ब्राउज़र कैश से किसी अस्पष्ट सर्टिफिकेट को कॉपी न करें, एंडपॉइंट पहचान को बंद न करें, एक अत्यधिक अनुमेय (permissive) ट्रस्ट मैनेजर इंस्टॉल न करें, या curl -k शिप न करें। सुधार के बाद, वास्तविक वर्कर, ब्राउज़र, curl, प्रत्येक एज एड्रेस, पिछले सर्टिफिकेट को हटाने, समाप्ति से पहले निगरानी, और जानबूझकर गलत होस्टनेम और एक अविश्वसनीय टेस्ट चेन के लिए विफलता व्यवहार को सत्यापित करें।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं यह निष्कर्ष नहीं निकालूंगा कि ब्राउज़र काम करता है इसलिए Java गलत है। प्रत्येक सत्यापनकर्ता अपने स्वयं के लक्षित सर्टिफिकेट, इंटरमीडिएट सेट, ट्रस्ट एंकर, संदर्भ आइडेंटिटी, समय और नीति से निर्णय लेता है।

मैं चार जांचों को अलग करता हूं। पहला, पाथ निर्माण लीफ से इंटरमीडिएट्स के माध्यम से स्थानीय रूप से विश्वसनीय एंकर तक एक अनुक्रम पाता है। सर्वर द्वारा भेजे गए सर्टिफिकेट केवल निर्माण इनपुट हैं; वे ट्रस्ट नहीं बनाते हैं। दूसरा, पाथ वैलिडेशन सिग्नेचर, वैधता, CA और की कंस्ट्रेंट्स, क्रिटिकल एक्सटेंशन, एल्गोरिदम, नीतियों और सर्वर-ऑथ उद्देश्य को सत्यापित करता है। तीसरा, एंडपॉइंट पहचान कॉन्फ़िगर किए गए नाम की SAN से तुलना करती है। एक DNS URL को DNS-ID की आवश्यकता होती है, जबकि एक IP-लिटरल URL को IP-ID की आवश्यकता होती है। SNI केवल वर्चुअल होस्ट के सर्टिफिकेट का चयन करता है। चौथा, TLS यह साबित करने के लिए CertificateVerify को सत्यापित करता है कि पीयर के पास इस हैंडशेक के लिए लीफ प्राइवेट की है।

ब्राउज़र में एक अलग रूट स्टोर, कैश्ड या खोजा गया इंटरमीडिएट, या एक एंटरप्राइज प्रॉक्सी रूट हो सकता है। Java 21 वर्कर के कस्टम ट्रस्टस्टोर में आवश्यक एंकर या निर्माण इनपुट की कमी हो सकती है, और इसका एक्सेप्शन केवल यह कहता है कि कोई स्वीकार्य पाथ नहीं बनाया गया था। IP curl विफलता अपेक्षित है यदि सर्टिफिकेट DNS नाम को कवर करता है लेकिन इसमें कोई IP SAN नहीं है।

मैं सबसे पहले openssl s_client, सही SNI, -verify_return_error, और -verify_hostname के साथ सटीक चेन को कैप्चर करूंगा। मैं SANs, जारीकर्ताओं, वैधता, बेसिक कंस्ट्रेंट्स, की उपयोग, EKU, एल्गोरिदम और फ़िंगरप्रिंट्स की सूची बनाऊंगा। फिर मैं सहेजे गए लीफ और सर्व किए गए इंटरमीडिएट्स को वर्कर के रूट्स के एक अनुमोदित निर्यात के विरुद्ध वैलिडेट करूंगा, और इसके वास्तविक रनटाइम फ़्लैग के साथ Java कंटेनर के अंदर पुन: उत्पन्न करूंगा। curl --resolve मुझे URL आइडेंटिटी और SNI दोनों के रूप में api.example.com को बनाए रखते हुए प्रत्येक लोड-बैलेंसर IP का परीक्षण करने की अनुमति देता है।

यदि कोई इंटरमीडिएट गायब है, तो मैं सभी TLS टर्मिनेटरों पर चेन बंडल को ठीक करता हूं। यदि कोई अनुमोदित निजी या प्रॉक्सी रूट अनुपस्थित है, तो मैं लीफ पर भरोसा करने के बजाय प्रबंधित ट्रस्टस्टोर वर्कफ़्लो के माध्यम से उस रूट को वितरित करता हूं। यदि SAN, घड़ी या नीति गलत है, तो मैं उस सटीक लेयर की मरम्मत करता हूं। मैं कभी भी ट्रस्ट-ऑल का उपयोग नहीं करता, होस्टनेम वेरिफिकेशन को डिसेबल नहीं करता, या -k को फिक्स के रूप में स्वीकार नहीं करता। मैं इस घटना को तभी बंद करता हूं जब वास्तविक वर्कर प्रत्येक एज पर सफल हो जाता है और नकारात्मक परीक्षण अभी भी गलत होस्टनेम और एक अविश्वसनीय चेन को अस्वीकार करते हैं।"

सामान्य गलतियाँ

• चेन निर्माण और वैलिडेशन को एक ही ऑपरेशन मानना → क्लाइंट्स वैलिडेशन से पहले विभिन्न संभावित पाथ्स की खोज कर सकते हैं → लक्षित, इंटरमीडिएट सेट, ट्रस्ट एंकर, और पॉलिसी को अलग से नामित करें।
• रूट पर केवल इसलिए भरोसा करना क्योंकि सर्वर ने इसे भेजा है → ट्रस्ट एंकर स्थानीय नीति से आते हैं → सर्वर द्वारा प्रदान किए गए सर्टिफिकेट्स को अविश्वसनीय निर्माण इनपुट के रूप में मानें।
• सिग्नेचर की जांच करना लेकिन CA कंस्ट्रेंट्स को छोड़ देना → केवल एक वैध सिग्नेचर किसी जारीकर्ता को सर्टिफिकेट पर हस्ताक्षर करने के लिए अधिकृत नहीं करता है → बेसिक कंस्ट्रेंट्स, पाथ की लंबाई, की उपयोग, क्रिटिकल एक्सटेंशन, और उद्देश्य की जांच करें।
• सर्टिफिकेट के नाम को अपेक्षित आइडेंटिटी के रूप में उपयोग करना → यह प्रस्तुत डेटा को यह चुनने की अनुमति देता है कि उसे क्या साबित करना चाहिए → कॉन्फ़िगर किए गए URL से संदर्भ आइडेंटिटी प्राप्त करें।
• यह मान लेना कि SNI होस्टनेम वेरिफिकेशन करता है → SNI एक वर्चुअल होस्ट का चयन करता है → एक अलग क्लाइंट जांच के रूप में SAN मिलान करें।
• एक IP URL को वैलिडेट करने के लिए DNS SAN की अपेक्षा करना → DNS-ID और IP-ID विभिन्न प्रकार हैं → DNS आइडेंटिटी को बनाए रखते हुए रूटिंग को पिन करने के लक्ष्य के लिए --resolve का उपयोग करें।
• एक एक्सेप्शन से केवल एक अनुपलब्ध इंटरमीडिएट को दोष देना → ट्रस्टस्टोर, पॉलिसी, समय, प्रॉक्सी, और डिप्लॉयमेंट विषमता समान लक्षण पैदा कर सकते हैं → वास्तविक चेन को कैप्चर करें और सटीक रनटाइम इनपुट के साथ पुन: उत्पन्न करें।
• -k या ट्रस्ट-ऑल के साथ मरम्मत करना → यह एक प्रमाणित चैनल को एक अप्रमाणित चैनल में परिवर्तित करता है → चेन, आइडेंटिटी, प्रबंधित रूट, घड़ी, या पॉलिसी को ठीक करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: क्या सर्वर को रूट सर्टिफिकेट भेजना चाहिए?

आमतौर पर नहीं। सर्वर को लीफ और उस रूट तक पहुंचने के लिए आवश्यक इंटरमीडिएट्स भेजने चाहिए जिस पर क्लाइंट पहले से भरोसा करता है। सर्वर द्वारा भेजा गया रूट उस क्लाइंट के लिए निरर्थक (redundant) है जो उस पर भरोसा करता है और उस क्लाइंट के लिए शक्तिहीन है जो नहीं करता। यह हैंडशेक बाइट्स को भी बर्बाद करता है।

फॉलो-अप 2: एक ब्राउज़र अनुपलब्ध इंटरमीडिएट से कैसे उबर सकता है जबकि दूसरा क्लाइंट विफल हो जाता है?

कार्यान्वयन (Implementations) में विभिन्न इंटरमीडिएट कैश या खोज व्यवहार हो सकते हैं। एक ब्राउज़र के पास पहले से ही इंटरमीडिएट हो सकता है या वह कार्यान्वयन-विशिष्ट तंत्र के माध्यम से इसे प्राप्त कर सकता है, जबकि एक अलग-थलग (isolated) वर्कर के पास केवल हैंडशेक और उसका कस्टम स्टोर होता है। यही कारण है कि सर्वर को क्लाइंट रिकवरी पर भरोसा करने के बजाय आवश्यक इंटरमीडिएट्स डिलीवर करने चाहिए। यह मानने के बजाय कि प्रत्येक ब्राउज़र समान व्यवहार करता है, वास्तविक पाथ की पुष्टि करें।

फॉलो-अप 3: क्या मेल खाने वाला होस्टनेम एक सेल्फ-साइन्ड सर्टिफिकेट को सुरक्षित बनाता है?

नहीं। आइडेंटिटी मैचिंग और पाथ ट्रस्ट स्वतंत्र हैं। एक सर्टिफिकेट में सही DNS SAN हो सकता है फिर भी स्थानीय रूप से विश्वसनीय एंकर के लिए कोई पाथ नहीं हो सकता है। एक निजी डिप्लॉयमेंट नियंत्रित प्रावधान के माध्यम से एक सेल्फ-साइन्ड रूट पर भरोसा कर सकता है, लेकिन केवल नाम का मिलान करने से वह ट्रस्ट स्थापित नहीं होता है।

फॉलो-अप 4: इंटरव्यू के उत्तर में निरस्तीकरण (revocation) पर कैसे चर्चा की जानी चाहिए?

नीति की सीमा बताएं। CRLs, OCSP, स्टेपलिंग, कैश्ड स्थिति, नेटवर्क एक्सेस, और सॉफ्ट-फेल या हार्ड-फेल नियम विभिन्न क्लाइंट्स में भिन्न होते हैं। निर्धारित करें कि वास्तविक सत्यापनकर्ता क्या जांचता है और जब स्थिति अनुपलब्ध होती है तो वह कैसा व्यवहार करता है। यह दावा न करें कि सभी क्लाइंट समान ऑनलाइन जांच करते हैं, और किसी आउटेज को खत्म करने के लिए आवश्यक हार्ड-फेल नीति को चुपचाप कमजोर न करें।

फॉलो-अप 5: कौन से साक्ष्य इस घटना को समाप्त (close) करते हैं?

प्रत्येक एज के लिए सर्व की गई लीफ और इंटरमीडिएट फ़िंगरप्रिंट, वर्कर के सटीक रूट्स के तहत निर्मित पाथ, सफल DNS-नाम और प्राइवेट-की प्रूफ, और सफल वास्तविक वर्कर अनुरोधों को रिकॉर्ड करें। गलत DNS नाम, IP-ID के बिना IP लिटरल, और एक अविश्वसनीय चेन के लिए नकारात्मक परीक्षण जोड़ें। पुष्टि करें कि कोई बाईपास शेष नहीं है, सभी लोड-बैलेंसर इंस्टेंस इच्छित बंडल की सेवा करते हैं, निगरानी समाप्ति और रोटेशन को कवर करती है, और किसी भी अस्थायी रूट या डायग्नोस्टिक आर्टिफैक्ट का एक मालिक और हटाने की तारीख है।