क्रस-साइन गरिएको 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: पुरानो मार्गलाई अवकाश घडीमा राख्नुहोस्

क्रस-साइनिङले डिजाइनअनुसार पुरानो विश्वास मार्ग जीवित राख्छ, जो एकैचोटि उद्देश्य र जोखिम हो। यसले सम्झौता भएको पुरानो रुट उपचार गर्दैन, र त्यो रुट कुनै पनि क्लाइन्टबाट हटाउँदैन। पुरानो मार्ग कहिले विश्वास दिन छाड्छ लेख्नुहोस्, र त्यो दिन साँच्चै आउँछ भनी पुष्टि गर्नुहोस्।

यदि हरेक क्लाइन्टले लिफ सर्नु अघि नयाँ रुट लिन सक्छ भने, साधारण दोहोरो-विश्वास रोलआउट क्रस-साइनिङभन्दा सरल छ, र अवकाश गर्न एक चीज कम छाड्छ।