OCSP بمقابلہ CRL: ہر منسوخی جانچ واقعی کیسے کام کرتی ہے

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

مرحلہ 1: ہر جانچ کیا واپس دیتی ہے اور کتنی دیر قابلِ استعمال رہتی ہے

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

اسی لیے کیشنگ پہلی چیز ہے جو طے کرنی ہے: کون سا جزو نقل رکھتا ہے، اور وہ نقل کس بالائی حد کی پابند ہے۔ گیٹ وے پر حد nextUpdate منفی حفاظتی مارجن ہونی چاہیے، کبھی بھی وہ نہیں جو کوئی HTTP کیش ہیڈر اتفاقاً تجویز کرے۔ openssl crl -in issuer.crl -noout -lastupdate -nextupdate دونوں تاریخیں چھاپتا ہے، اور جس فہرست کا nextUpdate پہلے ہی ماضی میں ہے اسے محض پرانی نہیں بلکہ غائب سمجھا جانا چاہیے۔

مرحلہ 2: سرٹیفکیٹ کلائنٹ کو کہاں بھیجتا ہے

لیف سرٹیفکیٹ عام طور پر دو اشارے رکھتا ہے: CRL تقسیم نقطہ کی توسیع اور OCSP کے لیے اتھارٹی معلومات تک رسائی کا اندراج۔ openssl x509 -in client.pem -noout -ext crlDistributionPoints پہلا چھاپتا ہے، اور دوسرا openssl x509 -in client.pem -noout -text کے AIA حصے کے تحت ہے۔ کوئی بھی توسیع اشارہ ہے، پابندی نہیں۔ جو کلائنٹ کبھی منسوخی جانچ نافذ نہیں کرتا وہ ایسے سرٹیفکیٹ سے بخوبی جڑ جائے گا جس کی توسیعات ایک سال سے مردہ جواب دہندہ کا نام دیتی ہیں۔

تقسیم کے نقطے اکثر ایسے اندرونی میزبان کا نام دیتے ہیں جو صرف ایک نیٹ ورک قطعے کے اندر حل ہوتا ہے، اور کچھ پرانے کلائنٹ ldap URLs کو یکسر رد کر دیتے ہیں۔ رسائی اُس میزبان سے جانچیں جو ٹنل ختم کرتا ہے، اپنے لیپ ٹاپ سے نہیں، کیونکہ وہی واحد نقطہ نظر ہے جس کی ناکامی واقعی اہمیت رکھتی ہے۔

مرحلہ 3: خلل سے پہلے fail-closed یا fail-open منتخب کریں

ناقابلِ رسائی جواب دہندہ یا میعاد گزری فہرست فیصلہ تھوپتی ہے: کنکشن رد کریں، یا قبول کریں اور خلا درج کریں۔ OpenSSL کا verify ذیلی حکم سخت انتخاب کو واضح کرتا ہے، کیونکہ -crl_check شامل کرنے سے دستیاب نہ ہونے والی CRL unable to get certificate CRL اور ناکام تصدیق بن جاتی ہے۔ بیشتر اسٹیکس میں نرم ناکامی کوئی جھنڈا نہیں ہوتی، وہ جانچ کی عدم موجودگی ہے، اور اسی لیے وہ حادثاتی طور پر بھیجی جاتی ہے۔

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

مرحلہ 4: ثابت کریں کہ جانچ وہیں چلتی ہے جہاں ٹریفک قبول کی جاتی ہے

وہ عمل تلاش کریں جو کنکشن ختم یا مجاز کرتا ہے، پھر اس سے وہ کنفیگریشن سطر پوچھیں جو منسوخی جانچ فعال کرتی ہے۔ جو گیٹ وے زنجیر کی تصدیق کرتا ہے مگر کبھی منسوخی کے بارے میں نہیں پوچھتا وہ آپ کی دستاویزات والی پالیسی سے مختلف پالیسی نافذ کرتا ہے، اور سرٹیفکیٹ زنجیر کا کوئی اسکرین شاٹ اس کے برعکس ثابت نہیں کرتا۔ OpenVPN اس اختیار کو crl-verify لکھتا ہے؛ strongSwan CRL اور OCSP تلاشیں CA کنفیگریشن کے تحت رکھتا ہے، جہاں crl_uris یا ocsp_uris مقرر کیے جاتے ہیں۔ اگر آپ دونوں میں سے کسی کی طرف اشارہ نہیں کر سکتے تو مان لیں کہ جانچ موجود نہیں۔

OCSP جواب صرف اسی وقت معتبر ہے جب جاری کرنے والی CA نے اس پر دستخط کیے ہوں، یا جب اُس CA کے تفویض کردہ OCSPSigning توسیع شدہ کلید استعمال والا جواب دہندہ اس پر دستخط کرے، لہٰذا غیر متعلق سروس کا جواب کچھ ثابت نہیں کرتا۔ اگر آپ خود جواب دہندہ چلاتے ہیں تو اس کی سخت انحصار کے طور پر نگرانی کریں، کیونکہ ایک مردہ سروس ایک ہی وقت میں ہر fail-closed کلائنٹ کے لیے خلل بن جاتی ہے۔

مرحلہ 5: جان بوجھ کر ایک سرٹیفکیٹ منسوخ کریں

ایک آزمائشی سرٹیفکیٹ لیں، اسے اسی چینل سے منسوخ کریں جو پیداوار استعمال کرتی ہے، اور جواب دہندہ سے براہِ راست پوچھیں۔ openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text کو منسوخی کے وقت کے ساتھ Cert Status: revoked کی اطلاع دینی چاہیے، اور good جواب کا مطلب ہے کہ آپ کی منسوخی اُس جواب دہندہ تک نہیں پہنچی جس سے آپ کے کلائنٹ پوچھتے ہیں۔ پھر فہرست کے راستے وہی فیصلہ دیکھنے کے لیے openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem چلائیں۔ exit کوڈ کے بجائے وجہ کی سٹرنگ پڑھیں، کیونکہ منسوخی کی تردید اور زنجیر کی خرابی دونوں ناکامی پر ختم ہوتی ہیں۔

جو مرحلہ واقعی اہم ہے وہ آخری ہے: پرانی پروفائل کے ساتھ اصل نفاذ کے مقام پر دوبارہ جڑیں اور تصدیق کریں کہ تردید منسوخی ہی سے آتی ہے۔ پھر نئے، معتبر سرٹیفکیٹ کے ساتھ دوبارہ جڑیں تاکہ ثابت ہو کہ آپ نے صرف سننے والا نہیں توڑا۔ کلائنٹ پر پروفائل مٹانا سرور کے فیصلے کے بارے میں کچھ ثابت نہیں کرتا، اور ایسا اُس مشین پر کامیاب openssl verify چلانا بھی نہیں جو کبھی ٹنل ختم نہیں کرتی۔ RFC 6960 متعین کرتا ہے کہ موافق OCSP جواب میں کیا ہوتا ہے، بشمول وہ حیثیت کی قدریں جو یہ آزمائش پڑھتی ہے۔