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 بغیر خرابی کے واپس آتی ہے۔ پھر مقررہ اجراء بحال کریں اور پہلی بار چلنے پر نظر رکھیں، کیونکہ دوسری بگڑی ہوئی سطر فوراً خود کو ظاہر کر دے گی۔