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

दोन CA प्रमाणपत्रे एकच सार्वजनिक की आणि एकच subject ठेवू शकतात आणि तरीही अदलाबदल करण्यायोग्य नसतात. एक स्व-स्वाक्षरीत आहे, दुसरे जुन्या रूटने क्रॉस-स्वाक्षरीत केलेले आहे, आणि त्यांची जारीकर्ता नावे, अनुक्रमांक आणि स्वाक्षऱ्या वेगळ्या आहेत. लीफ तिच्या Authority Key Identifier द्वारे विशिष्टपणे त्यातील एकाशी बांधली जाऊ शकते. ते बाइंडिंग क्लायंटने चुकीची साखळी निवडेपर्यंत आणि handshake स्पष्ट कारणाशिवाय अयशस्वी होईपर्यंत अदृश्य राहते.

या पाच तपासण्या क्रमाने करा: प्रत्येक वेगळ्या अपयशाला वगळते.

तपासणी 1: टेम्पलेटला स्पर्श करण्यापूर्वी दोन्ही साखळ्या काढा

मार्ग लिहून ठेवा. जुनी लोकसंख्या जुन्या रूट A वर विश्वास ठेवते, ज्याने CA B जारी केले, ज्याने सर्व्हरचे लीफ जारी केले. नवीन लोकसंख्या स्व-स्वाक्षरीत CA B वर थेट विश्वास ठेवते. दोन्ही B प्रमाणपत्रे एकच की आणि subject ठेवतात, आणि म्हणूनच subject ओळ वाचणाऱ्या व्यक्तीला एक CA दिसते तिथे क्लायंटला दोन दिसतात.

क्रॉस-स्वाक्षरीत प्रतही खरे CA प्रमाणपत्र असले पाहिजे, ज्यात basic constraints आणि key usage स्वाक्षरीला परवानगी देतात.

तपासणी 2: फक्त की नाही, AKI फील्डची तुलना करा

लीफचे जारीकर्ता नाव B च्या subject शी जुळले पाहिजे, आणि तो भाग सहसा टिकतो. दोन प्रती वेगळ्या होण्याची जागा 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: जुना मार्ग निवृत्ती घड्याळावर ठेवा

क्रॉस-साइनिंग रचनेनुसार जुना विश्वास-मार्ग जिवंत ठेवते, जे एकाच वेळी हेतू आणि धोका आहे. ते तडजोड झालेल्या जुन्या रूटवर उपचार करत नाही, आणि ती रूट कोणत्याही क्लायंटमधून काढत नाही. जुना मार्ग कधी विश्वास देणे थांबवेल ते लिहा, आणि तो दिवस खरोखर येतो याची खात्री करा.

जर प्रत्येक क्लायंट लीफ हलण्यापूर्वी नवीन रूट घेऊ शकत असेल, तर साधे दुहेरी-विश्वास रोलआउट क्रॉस-साइनिंगपेक्षा सोपे आहे, आणि निवृत्त करण्यासाठी एक गोष्ट कमी ठेवते.