openssl ca: تاريخ انتهاء صلاحية غير صالح في index.txt، وكيفية إصلاحه

تتوقف عملية إصدار عند entry 22: invalid expiry date، والطلب الذي أمامك سليم تمامًا. الشكوى تأتي من محلِّل قاعدة بيانات CA، لا من طلب التوقيع ولا من عميل VPN الذي سيعرض الشهادة في النهاية. هذا التمييز يحدد كل ما يليه: السجل مشوَّه، لذا فإن الإصلاح مكانه حالة CA لا الطلب ولا إعداد النظير. تعامل مع القيد المرقَّم كسطر في index.txt، فتتقلص المشكلة إلى سؤال بيانات محدود له جواب قابل للتحقق.

اقرأ الخطأ كشكوى خاصة بقاعدة البيانات

كل openssl ca استدعاء يمر على قاعدة بياناته النصية قبل أن يوقّع أي شيء. كل سطر يحمل حرف حالة، وطابع وقت انتهاء، وطابع إلغاء اختياري، ورقمًا تسلسليًا بالنظام الست عشري، واسم ملف، والاسم المميز. وعندما يتعذر تحليل حقل واحد، يبلّغ الأمر عن رقم السطر ويتوقف بدلًا من التخمين في بقية السجل.

هذا التوقف وقائي لا تنطُّعي. السجل الذي لا تستطيع الأداة قراءته يتركها عاجزة عن تحديد ما إذا كان الاسم المميز المطلوب موجودًا أصلًا، أو ما إذا كان رقم تسلسلي قد صُرف، أو ما ينبغي أن تحتويه قائمة الإلغاء التالية. والمضي قدمًا بعد سطر فاسد ينتج بالضبط ذلك التعارض الصامت الذي يظهر بعد أشهر، عادة أثناء إلغاء لا يستطيع أحد تفسيره. اقرأ الرسالة كشكوى على البيانات، فيبقى التحقيق داخل دليل CA.

انسخ حالة CA قبل أن تلمس أي شيء

خذ لقطة للدليل الكامل لـ CA، لا لملف قاعدة البيانات وحده. الفهرس وملف سماته وملفا الرقم التسلسلي ورقم قائمة الإلغاء والمفتاح الخاص والشهادات الصادرة كلها تشارك في العمليات اللاحقة، والإصلاح الذي يعيد أحدها ويغفل البقية يخلق حادثة ثانية. استخدم روتين النسخ الاحتياطي الخاص بـ CA إن وُجد، وأوقف الإصدار المجدول طوال مدة العمل.

سجّل إصدار OpenSSL وملف الإعداد الذي حمَّله الأمر الفاشل فعلًا. فالتثبيتات كثيرًا ما تحتفظ بأكثر من دليل CA، ولا معنى للخطأ إلا مقابل قاعدة البيانات التي يسمّيها الإعداد المختار.

اعثر على القيد وفُكّ ترميز حقل تاريخه

رقم السطر المبلَّغ عنه يُعد من أول سجل، لذا فإن sed -n '22p' index.txt يقع على القيد المخالف بعد أن تتأكد من عدم وجود أسطر فارغة أو تعليقات فوقه. اطبع ذلك السطر بفواصل ظاهرة، لأن محارف الجدولة والمسافات في النهاية شائعة وغير مرئية في نافذة تحرير عادية.

حقل الانتهاء طابع زمني يعتمد عرضه على السنة. القيم حتى 2049 تُكتب بصيغة UTCTime على شكل YYMMDDHHMMSSZ، بينما تنتقل القيم اللاحقة إلى GeneralizedTime بسنة من أربعة أرقام. والسجل الذي يخلط بين الشكلين، أو الذي يحمل سنة من رقمين حيث يتوقع المحلل الآن أربعة، يفشل عند هذه النقطة بالضبط. وكذلك الحقل المبتور الذي يتركه كتابة متقطعة.

قارن السجل بالشهادة التي يشير إليها لا بملف CA آخر. فالشهادة الموقَّعة هي المرجع فيما ينبغي أن تقوله الصلاحية، وهي موجودة أصلًا ككائن قابل للتحليل.

أصلح السجل مقابل الشهادة الموقَّعة

اقرأ التواريخ الحقيقية بـ openssl x509 -in issued.pem -noout -dates -serial -subject. حوّل notAfter إلى عرض الطابع الذي يكتبه بناءك لتلك السنة، وتأكد من أن الرقم التسلسلي يطابق القيد الذي أنت على وشك تحريره قبل أن تغيّر حرفًا واحدًا.

حرّر الحقل المعطوب فقط، وأبقِ حرف الحالة والرقم التسلسلي، واترك بقية السطر كما هي. وإذا تعذر التوفيق بين السجل وأي شهادة موقَّعة، فاعتبره قيدًا شاردًا وأخرجه عبر مسار الإلغاء الخاص بـ CA بدلًا من حذف السطر يدويًا.

لا تصلح الأمر بقصّ التاريخ ليناسب تخمينًا عن السنة. فالقص بحرفين غير قابل للنقل بين عمليات البناء، وهو يغيّر بصمت الصلاحية التي تُبلغها قاعدة البيانات لفحوص الاسم المكرر وقائمة الإلغاء المستقبلية. وعندما تكون القيمة الأصلية غير قابلة للاستعادة، أعد الإصدار برقم تسلسلي جديد واكتب سبب التخلي عن القديم. فأثر التدقيق جزء من الإصلاح، لا ورق عمل حوله.

تحقق من الإصدار وتوليد قائمة الإلغاء قبل أن تنصرف

نفّذ عملية إصدار واحدة بالإعداد نفسه وتأكد من أنها تكتمل دون شكوى عن رقم سطر. ثم ولّد قائمة إلغاء بـ openssl ca -gencrl -config openssl.cnf وتحقّق من أنها تُحلَّل، لأن السجل التالف غالبًا ما يظهر هناك لا أثناء التوقيع.

افحص الشهادة الجديدة بـ openssl x509 -noout -dates -serial وقارنها بالسطر الذي كتبته CA للتو. تأكد من أن حرف الحالة وتاريخ الانتهاء يتفقان مع الشهادة، وتأكد من أن openssl verify -CAfile ca.pem issued.pem يعود دون خطأ. ثم أعد الإصدار المجدول وراقب التشغيل الأول، لأن سطرًا مشوَّهًا ثانيًا سيعلن عن نفسه فورًا.