openssl ca: index.txt में अमान्य समाप्ति तिथि, और इसे कैसे ठीक करें

एक जारी करने का रन यहाँ रुक जाता है: entry 22: invalid expiry date, जबकि आपके सामने रखा अनुरोध पूरी तरह ठीक है। शिकायत CA डेटाबेस के पार्सर से आती है, CSR से नहीं और उस VPN क्लाइंट से भी नहीं जो अंततः प्रमाणपत्र प्रस्तुत करेगा। यही अंतर आगे का सब कुछ तय करता है: रिकॉर्ड विकृत है, इसलिए मरम्मत CA की स्थिति में है, अनुरोध या पीयर कॉन्फ़िगरेशन में नहीं। क्रमांकित प्रविष्टि को index.txt की एक पंक्ति मानें, और समस्या एक सीमित डेटा प्रश्न तक सिमट जाती है जिसका उत्तर जाँचा जा सकता है।

त्रुटि को डेटाबेस की शिकायत के रूप में पढ़ें

हर openssl ca कॉल कुछ भी हस्ताक्षरित करने से पहले अपने टेक्स्ट डेटाबेस से गुज़रती है। हर पंक्ति में एक स्थिति अक्षर, समाप्ति का टाइमस्टैम्प, वैकल्पिक निरसन टाइमस्टैम्प, हेक्स में क्रमांक, फ़ाइल नाम और सब्जेक्ट होता है। जब एक फ़ील्ड पार्स नहीं होता, तो कमांड पंक्ति संख्या बताता है और बाकी रिकॉर्ड का अनुमान लगाने के बजाय रुक जाता है।

यह रुकना रक्षात्मक है, सनकी नहीं। जिस रिकॉर्ड को उपकरण पढ़ नहीं सकता, वह यह तय नहीं कर पाता कि माँगा गया सब्जेक्ट पहले से मौजूद है या नहीं, कोई क्रमांक दिया गया है या नहीं, या अगली CRL में क्या होना चाहिए। खराब पंक्ति से आगे बढ़ने से ठीक वही खामोश असंगति पैदा होती जो महीनों बाद, आमतौर पर ऐसे निरसन के दौरान सामने आती है जिसे कोई समझा नहीं सकता। संदेश को डेटा की शिकायत के रूप में पढ़ें, और जाँच CA निर्देशिका के भीतर ही रहती है।

कुछ भी छूने से पहले CA की स्थिति की प्रतिलिपि बनाएँ

पूरी CA निर्देशिका का स्नैपशॉट लें, केवल डेटाबेस फ़ाइल का नहीं। इंडेक्स, उसकी एट्रिब्यूट फ़ाइल, क्रमांक और CRL संख्या की फ़ाइलें, निजी कुंजी और जारी किए गए प्रमाणपत्र सभी आगे के कार्यों में भाग लेते हैं, और ऐसी मरम्मत जो एक को बहाल करके बाकी छोड़ दे, दूसरी घटना पैदा करती है। जहाँ हो वहाँ CA की अपनी बैकअप प्रक्रिया इस्तेमाल करें, और काम की अवधि में निर्धारित जारी करना रोक दें।

असफल कमांड ने वास्तव में कौन-सा OpenSSL बिल्ड और कॉन्फ़िगरेशन फ़ाइल लोड की, यह लिख लें। इंस्टॉलेशन अक्सर एक से अधिक CA निर्देशिकाएँ रखते हैं, और त्रुटि का अर्थ केवल उस डेटाबेस के सामने है जिसका नाम चुना गया कॉन्फ़िगरेशन लेता है।

प्रविष्टि खोजें और उसका तिथि फ़ील्ड डिकोड करें

बताई गई पंक्ति संख्या पहले रिकॉर्ड से गिनी जाती है, इसलिए sed -n '22p' index.txt समस्या वाली प्रविष्टि पर तभी पड़ता है जब आप पुष्टि कर लें कि उसके ऊपर कोई खाली या टिप्पणी पंक्ति नहीं है। उस पंक्ति को दृश्य विभाजकों के साथ प्रिंट करें, क्योंकि टैब और अंत में आने वाले स्पेस सामान्य हैं और साधारण एडिटर विंडो में अदृश्य रहते हैं।

समाप्ति फ़ील्ड एक टाइमस्टैम्प है जिसकी चौड़ाई वर्ष पर निर्भर करती है। 2049 तक के मान UTCTime में YYMMDDHHMMSSZ के रूप में लिखे जाते हैं, जबकि बाद के मान चार अंकों के वर्ष वाले GeneralizedTime पर चले जाते हैं। जो रिकॉर्ड दोनों रूपों को मिलाता है, या जहाँ पार्सर अब चार अंक चाहता है वहाँ दो अंकों का वर्ष रखता है, वह ठीक इसी बिंदु पर विफल होता है। वैसे ही टूटी हुई लेखन से बचा हुआ कटा हुआ फ़ील्ड भी।

रिकॉर्ड की तुलना किसी दूसरे CA की फ़ाइल से नहीं, बल्कि उस प्रमाणपत्र से करें जिसका वह उल्लेख करता है। हस्ताक्षरित प्रमाणपत्र इस बात का प्राधिकार है कि वैधता क्या कहनी चाहिए, और वह पहले से ही पार्स करने योग्य वस्तु के रूप में मौजूद है।

हस्ताक्षरित प्रमाणपत्र के अनुसार रिकॉर्ड की मरम्मत करें

वास्तविक तिथियाँ इसके साथ पढ़ें: openssl x509 -in issued.pem -noout -dates -serial -subject। इस notAfter को उस टाइमस्टैम्प चौड़ाई में बदलें जो आपका बिल्ड उस वर्ष के लिए लिखता है, और एक भी अक्षर बदलने से पहले पुष्टि करें कि क्रमांक उस प्रविष्टि से मेल खाता है जिसे आप संपादित करने वाले हैं।

केवल टूटा हुआ फ़ील्ड संपादित करें, स्थिति अक्षर और क्रमांक रखें, और पंक्ति के बाकी हिस्से को अछूता छोड़ दें। यदि रिकॉर्ड को किसी भी हस्ताक्षरित प्रमाणपत्र के साथ नहीं मिलाया जा सकता, तो उसे भटकी हुई प्रविष्टि मानें और पंक्ति को हाथ से हटाने के बजाय CA के अपने निरसन मार्ग से उसे सेवानिवृत्त करें।

वर्ष के बारे में अनुमान के अनुरूप बनाने के लिए तिथि काटकर मरम्मत न करें। दो अक्षरों का कटाव बिल्डों के बीच स्थानांतरणीय नहीं है, और यह चुपचाप उस वैधता को बदल देता है जो डेटाबेस भविष्य की डुप्लिकेट-सब्जेक्ट और CRL जाँचों को बताता है। जब मूल मान पुनर्प्राप्त न हो सके, तब नए क्रमांक के अंतर्गत पुनः जारी करें और लिखें कि पुराना क्यों छोड़ा गया। ऑडिट ट्रेल मरम्मत का हिस्सा है, उसके आसपास का कागज़ी काम नहीं।

जाने से पहले जारी करना और CRL निर्माण सत्यापित करें

उसी कॉन्फ़िगरेशन के साथ एक जारी करना चलाएँ और पुष्टि करें कि वह पंक्ति संख्या की शिकायत के बिना पूरा होता है। फिर openssl ca -gencrl -config openssl.cnf के साथ एक CRL बनाएँ और जाँचें कि वह पार्स होती है, क्योंकि क्षतिग्रस्त रिकॉर्ड अक्सर हस्ताक्षर के समय नहीं, बल्कि वहीं सामने आता है।

नए प्रमाणपत्र को इसके साथ जाँचें: openssl x509 -noout -dates -serial और CA द्वारा अभी लिखी गई पंक्ति से उसकी तुलना करें। पुष्टि करें कि स्थिति अक्षर और समाप्ति तिथि प्रमाणपत्र से मेल खाती है, और पुष्टि करें कि openssl verify -CAfile ca.pem issued.pem बिना त्रुटि के लौटता है। फिर निर्धारित जारी करना बहाल करें और पहले रन पर नज़र रखें, क्योंकि दूसरी विकृत पंक्ति तुरंत अपनी घोषणा कर देगी।