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

حاصل کرنے کا راستہ تصدیق کنندہ کے پاس ہے

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

کچھ بھی بدلنے سے پہلے سرٹیفکیٹ، تصدیق کنندہ، کوشش کا وقت اور درست اسٹیٹس کوڈ لکھ لیں۔

سرٹیفکیٹ سے اشاعت کا مقام پڑھیں

سرٹیفکیٹ بتاتا ہے کہ اس کی حالت کہاں ہے۔ CA کا پتہ اندازہ لگانے کے بجائے وہ فیلڈز پڑھیں۔

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

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

تصدیق کرنے والے آلے سے حصول کی جانچ کریں

حاصل کرنے کا امتحان اسی ماحول میں چلائیں جو واقعی تصدیق کرتا ہے، منظور شدہ سرٹیفکیٹ مواد کے ساتھ اور نجی کلیدوں کے بغیر۔

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

certutil چلانے سے سلسلہ تصدیق ہوتا ہے اور رپورٹ ملتی ہے کہ کون سی URL حاصل کرنے کی کوششیں کامیاب یا ناکام ہوئیں، جبکہ curl کال اسی میزبان سے ایک اشاعتی پتہ جانچتی ہے اور صرف اسٹیٹس کوڈ واپس دیتی ہے۔ قابل رسائی پتے سے ناکام حصول مواد یا دستخط کے مسائل کی طرف اشارہ کرتا ہے؛ کنکشن کی خرابی روٹنگ، DNS یا پراکسی کی طرف اشارہ کرتی ہے۔ دونوں نتائج رکھیں، کیونکہ ایک کامیاب حصول پورے سلسلے کے قابل استعمال ہونے کا ثبوت نہیں۔ نمونہ میزبان اور راستہ سرٹیفکیٹ میں ملنے والے تقسیم مقام سے بدل دیں۔

غائب ڈیٹا کو منسوخ حالت سے الگ کریں

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

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

متعلقہ مضامین