غلط VPN سرٹیفکیٹ منسوخ کیا؟ بحالی کے اختیارات اور حدود

کسی نے CA کنسول میں سرٹیفکیٹ منسوخ کیا اور اب صارف جڑ نہیں سکتا۔ پہلا ردِعمل منسوخی کو واپس کرنے کی تلاش ہے، اور زیادہ تر PKI میں ایسا ممکن نہیں: منسوخی سریل نمبر کے بارے میں اعلان شدہ حقیقت ہے، اور معاون واپسی کا راستہ نیا سرٹیفکیٹ ہے، الٹا ریکارڈ نہیں۔ نیچے دی گئی جانچ ترتیب سے کریں، کیونکہ کون سی مرمت کی اجازت ہے یہ وجہ کوڈ اور اس پر منحصر ہے کہ کلید کبھی ظاہر ہوئی تھی یا نہیں۔

سرٹیفکیٹ کی شناخت کریں، شخص کی نہیں

عام نام دہرائے جاتے ہیں۔ پچھلی سہ ماہی میں دوبارہ اندراج کرنے والے صارف کے پاس ایک ہی CN اور مختلف سریل نمبروں کے دو سرٹیفکیٹ ہو سکتے ہیں، اور ایک منسوخ کرنے سے دوسرا کام کرتا رہتا ہے۔ پہلے درست شے کا تعین کریں:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

سریل نمبر، جاری کرنے والا، منسوخی کی تاریخ اور CRL میں درج وجہ لکھیں۔ پھر تصدیق کریں کہ کون سے آلات وہ سریل نمبر پیش کرتے ہیں، کیونکہ منسوخ شدہ سرٹیفکیٹ اب بھی لیپ ٹاپ، فون اور اضافی راؤٹر پر نصب ہو سکتا ہے، اور صرف ایک تک پہنچنے والا متبادل دوسرا واقعہ پیدا کرتا ہے۔

ایک تیز رویے کی جانچ کچھ بدلے بغیر حالت کی تصدیق کرتی ہے:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

اگر یہ سرٹیفکیٹ کو منسوخ بتاتی ہے تو CRL اور کلائنٹ متفق ہیں؛ اگر یہ صاف تصدیق ہوتا ہے تو آپ کے ہاتھ میں موجود کلائنٹ منسوخ شدہ نہیں، اور تلاش جاری رہتی ہے۔

جانچیں کہ CA نے ہولڈ یا مستقل منسوخی استعمال کی

RFC 5280 certificateHold کو عارضی حالت اور removeFromCRL کو اسے آزاد کرنے والا اشارہ قرار دیتا ہے۔ وہ زندگی کا دورانیہ حقیقی ہے، لیکن یہ عام undo بٹن نہیں ہے۔ وجہ کوڈ پڑھنے سے پتہ چلتا ہے کہ جاری کرنے والے نے کبھی رہائی کی حمایت کا ارادہ کیا تھا یا نہیں۔

جال یہ سمجھنا ہے کہ عارضی ارادے کا مطلب عارضی ریکارڈ ہے۔ اگر CA اندراج میں keyCompromise یا cessationOfOperation ہے تو بٹن دبانے والے شخص کے ارادے سے قطع نظر سرٹیفکیٹ مستقل طور پر منسوخ ہے۔ اس کے برعکس، جس CA میں ہولڈ کی رہائی نافذ نہیں ہوتی، وہاں certificateHold سے نشان زد اندراج عملاً مستقل ہے، کیونکہ کوئی چیز کبھی رہائی شائع نہیں کرے گی۔

OpenSSL پر مبنی CA اس حد کو ظاہر کرتے ہیں۔ ca کمانڈ -crl_reason اقدار قبول کرتی ہے، جن میں certificateHold اور removeFromCRL شامل ہیں، لیکن ڈیلٹا CRL نہیں بناتی — OpenSSL CA دستاویزات اپنی CRL آؤٹ پٹ کے لیے یہ حد بتاتی ہیں۔ سریل نمبر محض چھوڑ دینے والا مکمل CRL "یہ اندراج جاری کر دیا گیا" کہنے والے ڈیلٹا سے مختلف اشاعتی ماڈل ہے، اس لیے OpenSSL پر مبنی VPN CA میں removeFromCRL چسپاں کرنے سے معیارات کے مطابق متعین رہائی نہیں بنتی۔

اگر کلید ظاہر ہوئی ہو سکتی ہے تو اسے بدلیں

منسوخ شدہ سرٹیفکیٹ یہ اعلان ہے کہ اس کلید پر مزید بھروسہ نہیں کیا جا سکتا۔ اگر منسوخی جوہر میں درست تھی — لیپ ٹاپ گم ہوا، کلید مشترکہ ڈسک پر نقل ہوئی، نجی کلید ٹکٹ میں چسپاں ہوئی — تو وہی سرٹیفکیٹ بحال کرنا ایک سیکیورٹی فیصلے کو الٹ دیتا ہے جو حسبِ منشا کام کر رہا تھا۔

اندراج کے عمل سے نئی کلید جوڑی جاری کریں، نئی پروفائل تقسیم کریں، اور پرانے سریل نمبر کو اس کی پوری زندگی منسوخ رہنے دیں۔ ہر وہ چیز اپ ڈیٹ کریں جو شناخت کو سریل نمبر یا فنگر پرنٹ سے جکڑتی ہے، جس میں داخلہ فہرستیں، آلات کی انوینٹری اور مخصوص سرٹیفکیٹ کی توقع کرنے والی نگرانی شامل ہے۔

پرانے کو بحال کرنے کی سہولت کی دلیل حقیقی ہے، لیکن اس کا جواب کھلے طور پر دینا چاہیے، خاموشی سے نہیں۔ "صارف کو آج رسائی چاہیے" جاری کرنے میں تیزی کا سبب ہے، ایسی کلید کی منسوخی واپس لینے کا سبب نہیں جس کا آپ حساب نہیں دے سکتے۔

اگر یہ انتظامی غلطی تھی تو کنٹرول میں بدلیں

جب منسوخی محض غلط تھی اور کلید کبھی ظاہر نہیں ہوئی، تو مرمت اب بھی ترمیم نہیں بلکہ کنٹرول شدہ تبدیلی ہے۔ جاری کرنے والے کا معاون عمل استعمال کریں، سریل نمبر اور اجرا کی تاریخ کو محفوظ رکھیں، اور دو پرکشش شارٹ کٹ سے بچیں: index.txt میں حالت کے حرف کو R سے واپس V میں بدلنا، اور اجرا کی سطر مٹانا تاکہ نیا سرٹیفکیٹ سریل نمبر دوبارہ استعمال کر سکے۔

OpenSSL CA میں ڈیٹا بیس ٹیب سے الگ ہے اور غلط پڑھنا آسان ہے، جو دستی ترمیم کو پرکشش بناتا ہے:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

اسے پڑھیں، لکھیں نہیں۔ فائل میں ترمیم بغیر کسی آڈٹ نشان کے اگلا CRL بدل دیتی ہے، اور اصل سطر رکھنے والا کوئی بھی دوسرا CA نمونہ یا بیک اپ بعد میں اس سے متفق نہیں ہوگا۔

متبادل جاری کرنے کے بعد، عام طریقہ کار سے نیا CRL شائع کریں اور کلائنٹس کو اسے لینے دیں۔ CRL ہٹانا، اس کی عمر صفر کرنا یا کلائنٹ پروفائل میں منسوخی کی جانچ غیر فعال کرنا CA کی جانب سے کبھی شائع کی گئی ہر دوسری منسوخی کو کمزور کر کے ایک صارف کو ٹھیک کرتا ہے۔

نئے داخلے کی تصدیق کریں اور ریکارڈ رکھیں

نئے کنکشن سے جانچیں، پہلے سے کھلے سیشن سے نہیں۔ زندہ ٹنل نئے ہینڈ شیک کی داخلہ جانچ دوبارہ نہیں چلا سکتی، اور CRL کیش کا مطلب ہے کہ کلائنٹ تازہ ہونے تک جڑتا رہ سکتا ہے۔ منقطع کریں، دوبارہ جڑیں، اور سرور لاگ میں تصدیق کریں کہ کون سا سریل نمبر قبول ہوا۔

جو ہوا اسے ابھی تازہ ہوتے ہوئے درج کریں: کون سا سریل نمبر منسوخ ہوا، کس نے، کس وجہ سے، کون سا متبادل جاری ہوا، اور CRL کب دوبارہ شائع ہوا۔ وہی ریکارڈ اگلی منسوخی نظرثانی کو ممکن بناتا ہے، اور یہ بھی ثبوت ہے کہ غلطی چھپائی نہیں بلکہ سنبھالی گئی۔

مستقبل میں مختصر معطلی کے لیے، اگر تعیناتی میں ہو تو داخلہ وقفہ کا طریقہ استعمال کریں — شناخت کی سطح پر غیر فعال اکاؤنٹ، ہٹائی گئی گروپ رکنیت، روکی گئی کلائنٹ پروفائل۔ یہ عارضی پالیسی فیصلے کو اس سوال سے الگ رکھتا ہے کہ جاری کردہ سرٹیفکیٹ اب بھی قابلِ اعتماد ہے یا نہیں، اور پہلی بار ضائع ہونے والا فرق بالکل یہی تھا۔