منسوخ شدہ VPN سرٹیفکیٹ اب بھی جڑتا ہے؟ CRL نفاذ جانچیں
منسوخ شدہ سرٹیفکیٹ اب بھی جڑتے ہیں جب CRL کبھی تصدیق کنندہ تک نہ پہنچے۔ اسی ترتیب سے جاری کنندہ، لوڈ شدہ سیریل نمبر، دوبارہ لوڈ کا رویہ اور فعال سیشن جانچیں۔
آپ نے سرٹیفکیٹ منسوخ کیا، نئی فہرست بنائی، مگر پرانا پروفائل اب بھی ٹنل کھڑا کرتا ہے۔ منسوخی بذات خود خراب نہیں: CRL ایک دستخط شدہ اعلان ہے کہ سیریل نمبر اب درست نہیں، اور یہ رسائی صرف اُس وقت بدلتا ہے جب TLS ختم کرنے والا جزو اُسے صحیح جاری کنندہ کے لیے لوڈ کرے، اس سے پہلے کہ قبولیت کا فیصلہ کرے۔ زیادہ تر ایسے واقعات وہیں ہیں، اور اسی لیے منسوخی اور انکار دو الگ حقیقتیں ہیں۔
نیچے دیے گئے پانچ معائنے ترتیب سے کریں اور پہلے ناکام ہونے والے پر رکیں، کیونکہ ہر اگلا معائنہ پچھلے کے درست ہونے کا مفروضہ رکھتا ہے۔
جانچیں کہ قبولیت کا فیصلہ کون سا جزو کرتا ہے
اُس عمل کا نام لیں جو کلائنٹ سرٹیفکیٹ کی تصدیق کرتا ہے، کیونکہ فہرست صرف وہی عمل نافذ کر سکتا ہے۔ OpenVPN سرور پر یہ خود ڈیمن ہے، crl-verify کے ساتھ ترتیب دیا گیا۔ ocserv میں یہ ocserv.conf میں crl سطر ہے۔ strongSwan میں ان پٹ لوڈ شدہ CRL ہیں strictcrlpolicy کے ساتھ۔ VPN کے سامنے TLS ختم کرنے والا پراکسی یا آلہ بھی اصل تصدیق کنندہ ہو سکتا ہے، اور اگر ایسا ہو تو اُس کے پیچھے والا ڈیمن کلائنٹ سرٹیفکیٹ کبھی نہیں دیکھتا۔
WireGuard الگ زمرے میں آتا ہے۔ اُس کے پاس نہ سرٹیفکیٹ ہیں نہ منسوخی کی فہرست؛ پیئر کو کنفیگریشن میں اُس کی عوامی کلید سے قبول کیا جاتا ہے، لہٰذا رسائی ختم کرنے کا مطلب وہ کلید ہٹانا ہے۔ اگر آپ صرف WireGuard والی تعیناتی میں CRL ڈھونڈ رہے ہیں تو وہ طریقہ کار وہاں نہیں ہے۔
کلائنٹ کی طرف کے جال سے بھی بچیں۔ وہ کلائنٹ جو سرور کا سرٹیفکیٹ پسند نہ آنے پر جڑنے سے انکار کرتا ہے، سرور کی زنجیر نافذ کر رہا ہے، اپنے اسناد منسوخ نہیں کر رہا۔ صارف کا سرٹیفکیٹ صرف وہیں منسوخ ہوتا ہے جہاں وہ صارف سرٹیفکیٹ تصدیق ہوتا ہے، اور یہ تقریباً ہمیشہ سرور کی طرف ہوتا ہے۔
جانچیں کہ فہرست کس جاری کنندہ کے لیے دستخط شدہ ہے
CRL ایک ہی جاری کنندہ CA تک محدود ہے۔ جڑ اور درمیانی CA کے ساتھ پتوں کے سرٹیفکیٹ درمیانی سے آتے ہیں، اس لیے اہم فہرست درمیانی کی CRL ہے؛ جڑ کی فہرست اُن پتوں کے بارے میں کچھ نہیں کہتی۔ غلط فائل کی طرف اشارہ کرنے والا تصدیق کنندہ اُسے خوش دلی سے پارس کرتا ہے، کوئی مماثل اندراج نہیں پاتا اور سب کچھ قبول کر لیتا ہے۔
ڈیمن کو چھونے سے پہلے جوڑ کی تصدیق کریں۔ سرٹیفکیٹ پر جاری کنندہ فہرست کے subject سے مماثل ہونا چاہیے:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateجب دونوں ایک ہی CA سے آئیں تو سرٹیفکیٹ کے لیے چھپا سیریل نمبر وہ قدر ہے جو فہرست میں آنا ضروری ہے۔ اگر وہ مماثل نہ ہوں تو آپ کے پاس غلط CRL یا اُس کی غلط نقل ہے۔
درستی اسی معائنے سے تعلق رکھتی ہے۔ ماضی کا nextUpdate فہرست کو پرانا کر دیتا ہے، اور بند طور پر ناکام ہونے والا تصدیق کنندہ تب صرف منسوخ شدہ کی بجائے ہر کلائنٹ کو مسترد کرے گا۔
جانچیں کہ سیریل نمبر اُس نقل میں ہے جو ڈیمن نے لوڈ کی
منسوخی CA ڈیٹا بیس میں اندراج لکھتی ہے، اور دوبارہ تخلیق نئی فائل لکھتی ہے۔ دونوں میں سے کوئی عمل ایسے چلتے ڈیمن تک نہیں پہنچتا جس نے آغاز پر پرانی نقل لوڈ کی ہو۔ فہرست ڈمپ کریں اور سیریل نمبر تلاش کریں:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlپھر جانچیں کہ آپ کا نفاذ فائل کو کیسے اُٹھاتا ہے۔ OpenVPN crl-verify کو دیا گیا راستہ آغاز پر ایک بار پڑھتا ہے، لہٰذا نئی فہرست کے لیے دوبارہ آغاز یا دوبارہ آغاز کا اشارہ درکار ہے؛ وہی اختیار جو کسی فولڈر کی طرف ہو ہر اتصال پر دوبارہ پڑھا جاتا ہے، اور اسی لیے فولڈر موڈ موجود ہے۔ strongSwan کو اپنے اسناد دوبارہ لوڈ کرنے ہوتے ہیں، مثلاً swanctl --load-creds کے ساتھ۔ فائل کا ڈسک پر درست ہونا اور تصدیق کنندہ کا اُسے استعمال کرنا دو الگ حقیقتیں ہیں۔
غائب یا میعاد ختم شدہ فہرست کی پالیسی جانچیں
یہ وہ فیصلہ ہے جو بہت سی تعیناتیاں کبھی واضح طور پر نہیں کرتیں، اور یہ طے کرتا ہے کہ منسوخی آپ کی حفاظت کرتی ہے یا سب کو باہر بند کر دیتی ہے۔ Fail-closed کا مطلب ہے کہ قابل استعمال منسوخی معلومات کے بغیر مسترد ہونا واقع ہوتا ہے؛ fail-open کا مطلب ہے کہ تصدیق کنندہ اُس کے بغیر آگے بڑھتا ہے۔ strongSwan انتخاب کو strictcrlpolicy کے طور پر پیش کرتا ہے۔ OpenVPN crl-verify کے ساتھ ایسی فائل پر شروع ہونے سے انکار کرتا ہے جسے وہ پڑھ یا پارس نہیں سکتا، اور میعاد ختم شدہ فہرست خاموش قبولیت کی بجائے میعاد ختم شدہ CRL کے بارے میں TLS تصدیقی خرابی کے طور پر ظاہر ہوتی ہے۔
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
آپ کوئی بھی سمت چنیں، خودکاری انتخاب سے زیادہ اہم ہے: ایسا کام جو CRL کو nextUpdate سے پہلے دوبارہ تخلیق کرے، اور ایسا انتباہ جب تعینات نقل پرانی ہو، دونوں پالیسیوں کو واقعہ بننے سے روکتے ہیں۔ OCSP کے ساتھ آن لائن جانچ تازگی کو جواب دہندہ کی طرف منتقل کرتی ہے، مگر وہی قاعدہ لاگو ہے، کیونکہ جواب کی جانچ کے لیے ترتیب نہ دیا گیا تصدیق کنندہ کچھ نہیں بدلتا۔
فعال سیشن جانچیں، پھر کلید کی نقول
منسوخی سرٹیفکیٹ کی تصدیق کے دوران جانچی جاتی ہے، جو جڑنے اور دوبارہ مذاکرات کے وقت ہوتی ہے۔ قائم سیشن اُس وقت تک جاری رہتا ہے جب تک دوبارہ مذاکرات نہ کرے، اور OpenVPN کی طے شدہ قدر reneg-sec 3600 کے ساتھ گھنٹے میں ایک بار ہے۔ اگر شخص کو ابھی نیٹ ورک سے باہر جانا ہے تو فہرست کی اشاعت کے ساتھ سیشن بھی ختم کریں، پھر تصدیق کریں کہ دوبارہ اتصال مسترد ہوتا ہے۔
اسناد کو اُن کی نقول سے الگ کریں۔ ایک لیپ ٹاپ پر پروفائل حذف کرنا اُسی نجی کلید کی دوسری نقل کو تصدیق سے نہیں روکتا؛ منسوخی ہی ہر نقل کو بے کار بناتی ہے، اور صرف اُس وقت جب پچھلے معائنے درست ہوں۔ متبادل آلے کو اپنا سرٹیفکیٹ دیں تاکہ ایک کو دوسرے کو چھوئے بغیر منسوخ کیا جا سکے۔
اسے مکمل کہنے سے پہلے: تصدیق کرنے والا جزو شناخت ہو چکا ہے، فہرست کا جاری کنندہ پتے کے جاری کنندہ سے مماثل ہے، منسوخ شدہ سیریل نمبر اُس نقل میں ہے جو ڈیمن نے واقعی لوڈ کی، غائب یا میعاد ختم شدہ فہرستوں کی پالیسی دانستہ اور زیر نگرانی ہے، اور فعال سیشن کا انتظار کرنے کی بجائے اُسے ختم کیا گیا ہے۔ اِن سب کے پیچھے کے فارمیٹ RFC 5280 میں متعین ہیں۔