क्रॉस-साइन्ड CA: कुंजी मेल खाती है, AKI बाइंडिंग नहीं

दो CA प्रमाणपत्र एक ही सार्वजनिक कुंजी और एक ही सब्जेक्ट रख सकते हैं और फिर भी विनिमेय नहीं होते। एक स्व-हस्ताक्षरित है, दूसरा पुरानी रूट द्वारा क्रॉस-हस्ताक्षरित है, और उनके जारीकर्ता नाम, क्रमांक और हस्ताक्षर अलग हैं। एक लीफ अपने Authority Key Identifier के ज़रिये विशेष रूप से इनमें से एक से बंध सकता है। यह बंधन तब तक अदृश्य रहता है जब तक कोई क्लाइंट गलत श्रृंखला चुन न ले और handshake बिना किसी स्पष्ट कारण के विफल हो जाए।

ये पाँच जाँचें क्रम से करें: हर एक अलग विफलता को रद्द करती है।

जाँच 1: टेम्पलेट छूने से पहले दोनों श्रृंखलाएँ बनाएँ

पथ लिख लें। पुरानी आबादी पुरानी रूट A पर भरोसा करती है, जिसने CA B जारी किया, जिसने सर्वर का लीफ जारी किया। नई आबादी सीधे स्व-हस्ताक्षरित CA B पर भरोसा करती है। दोनों B प्रमाणपत्र एक ही कुंजी और सब्जेक्ट रखते हैं, और ठीक इसी कारण सब्जेक्ट पंक्ति पढ़ने वाला व्यक्ति एक CA देखता है जहाँ क्लाइंट दो देखता है।

क्रॉस-हस्ताक्षरित प्रति भी असली CA प्रमाणपत्र होनी चाहिए, जिसमें basic constraints और key usage हस्ताक्षर की अनुमति दें।

जाँच 2: केवल कुंजी नहीं, AKI फ़ील्ड की तुलना करें

लीफ के जारीकर्ता नाम को B के सब्जेक्ट से मेल खाना चाहिए, और यह हिस्सा आमतौर पर सही रहता है। Authority Key Identifier वह जगह है जहाँ दोनों प्रतियाँ अलग होती हैं, क्योंकि वह कुंजी पहचानकर्ता, जारीकर्ता प्रमाणपत्र और क्रमांक रख सकता है। कुंजी पहचानकर्ता दोनों प्रतियों से मेल खाता है, क्योंकि कुंजी एक जैसी है। जारीकर्ता और क्रमांक फ़ील्ड ठीक एक से मेल खाते हैं, इसीलिए स्व-हस्ताक्षरित प्रति के विरुद्ध बनने वाली श्रृंखला क्रॉस-हस्ताक्षरित के विरुद्ध विफल हो सकती है।

अनुमान लगाने के बजाय लीफ देखें: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier।

फिर दोनों उम्मीदवारों की openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" से तुलना करें, और वही कमांड स्व-हस्ताक्षरित प्रति पर चलाएँ।

अगर लीफ जारीकर्ता और क्रमांक रखता है, तो केवल वही प्रमाणपत्र श्रृंखला पूरी करता है जिसे ये मान बताते हैं, क्लाइंट ने कोई भी प्रति लोड की हो।

जाँच 3: जारीकरण नीति बदलें, हस्ताक्षरित बाइट कभी नहीं

एक्सटेंशन हस्ताक्षर के भीतर रहते हैं। मौजूदा लीफ पर एक जोड़ना, हटाना या संपादित करना मरम्मत नहीं है, यह अलग प्रमाणपत्र है, और इसे पुनः जारी करना पड़ता है। बदलाव जारीकरण नीति में आता है: authorityKeyIdentifier = keyid,issuer:always नए लीफ को प्रमाणपत्र-विशिष्ट बंधन रखने देता है, जबकि अकेला keyid ढीला रूप रखता है जो जान-बूझकर किए गए क्रॉस-हस्ताक्षर संक्रमण के लिए उपयुक्त है। अगला बैच हस्ताक्षरित होने से पहले तय करें कि आपकी PKI क्या चाहती है।

साझा टेम्पलेट संपादित करने से हर भावी प्रमाणपत्र भी बदलता है, केवल आपके सामने का सर्वर नहीं।

जाँच 4: हर भरोसा-आबादी को अलग से सत्यापित करें

पुराने पथ और नए पथ को अलग-अलग रन के रूप में परखें। openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem क्रॉस-हस्ताक्षरित मार्ग का अभ्यास करता है, और नई रूट तथा untrusted फ़ाइल के बिना वही कमांड स्व-हस्ताक्षरित मार्ग का अभ्यास करता है। दोनों रूटों को एक बंडल में मिलाना छिपा देता है कि कौन-सी श्रृंखला चुनी गई। बाद में असली क्लाइंट के साथ दोहराएँ, क्योंकि VPN बैकएंड श्रृंखला को प्राथमिकता दे सकता है या प्रमाणपत्र पिन कर सकता है ऐसे तरीकों से जो openssl नहीं करता।

मध्यवर्ती प्रमाणपत्र उस सेवा कॉन्फ़िगरेशन से दें जिसे क्लाइंट वास्तव में पढ़ता है, विकी पृष्ठ से नहीं।

जाँच 5: पुराने पथ को सेवानिवृत्ति घड़ी पर रखें

क्रॉस-हस्ताक्षर डिज़ाइन से पुराना भरोसा-पथ जीवित रखता है, जो उद्देश्य और जोखिम दोनों है। यह किसी समझौते वाली पुरानी रूट का उपचार नहीं करता, और वह रूट किसी भी क्लाइंट से नहीं हटाता। लिख लें कि पुराना पथ कब भरोसा देना बंद करेगा, और पुष्टि करें कि वह दिन सचमुच आता है।

अगर हर क्लाइंट लीफ के हटने से पहले नई रूट अपना सके, तो सादा दोहरा-भरोसा रोलआउट क्रॉस-हस्ताक्षर से आसान है, और सेवानिवृत्त करने के लिए एक चीज़ कम छोड़ता है।