VPN سرٹیفکیٹ ابھی درست نہیں: تین وجوہات، جانچ کی ایک ترتیب
«ابھی درست نہیں» کا مطلب ہے کہ ڈیوائس کی گھڑی پیچھے ہے، ونڈو واقعی بعد میں شروع ہوتی ہے، یا درمیانی سرٹیفکیٹ ابھی کھلا نہیں۔ انہیں اسی ترتیب میں جانچیں۔
آپ کلائنٹ کھولتے ہیں، مہینوں سے استعمال شدہ پروفائل منتخب کرتے ہیں، اور یہ "certificate is not yet valid" کے ساتھ رک جاتا ہے۔ آپ کے سائن اِن میں کچھ نہیں بدلا، اور ٹرسٹ اسٹور غالباً ٹھیک ہے: ہینڈ شیک میں پیش کردہ سرٹیفکیٹ میں درستگی کی ونڈو ہے جو جانچنے والے کے استعمال کردہ لمحے کے بعد شروع ہوتی ہے۔ تین مختلف صورتیں یہی پیغام پیدا کرتی ہیں، اور ان کے لیے مختلف اقدامات درکار ہیں۔ نیچے دی گئی ترتیب بتاتی ہے کہ گھڑی یا سرٹیفکیٹ فائل چھونے سے پہلے آپ کے پاس کون سی صورت ہے۔
تین وجوہات میں سے آپ کون سی دیکھ رہے ہیں
پہلی وجہ مقامی ہے: جانچ کرنے والے ڈیوائس کی گھڑی سرٹیفکیٹ کی ابتدائی تاریخ سے پہلے کی ہے۔ یہ مردہ CMOS بیٹری والے ہارڈویئر پر، پرانے اسنیپ شاٹ سے بحال شدہ ورچوئل مشینوں پر، اتنی دیر بند رہنے والے آلات پر جنہوں نے وقت کھو دیا، اور ایسے نیٹ ورکس پر نظر آتی ہے جہاں باہر جانے والا NTP بلاک ہے اور کسی نے توجہ نہیں دی۔ سرٹیفکیٹ مکمل طور پر درست ہو سکتا ہے اور پھر بھی اس طرح ناکام ہو سکتا ہے۔
دوسری وجہ جاری کرنے والے کی ہے، کیونکہ سرٹیفکیٹ واقعی مستقبل میں شروع ہوتا ہے: جلدی جاری کیا گیا، واضح آغاز وقت کے ساتھ بنایا گیا، یا ایسے ایکٹیویشن مرحلے کے حصے کے طور پر دستخط شدہ جو ابھی نہیں چلا۔ تیسری وجہ سب سے زیادہ وقت ضائع کرتی ہے، کیونکہ پتا موجودہ ہے جبکہ پیش کردہ چین کا دوسرا سرٹیفکیٹ نہیں، اس لیے خرابی ایسے مواد کا نام لیتی ہے جو آپ نے کبھی انسٹال نہیں کیا۔
ایک سوال انہیں الگ کرتا ہے۔ کیا ناکامی ڈیوائس کے پیچھے چلتی ہے یا سروس کے؟ ایک ہی نیٹ ورک پر مختلف برتاؤ کرنے والی دو مشینیں گھڑیوں کی طرف اشارہ کرتی ہیں۔ اگر ہر کلائنٹ ایک ہی طرح ناکام ہو تو یہ سرٹیفکیٹ کی ونڈو اور اس کے پیچھے چین کی طرف اشارہ کرتا ہے۔
ونڈو اسی سرٹیفکیٹ سے پڑھیں جو واقعی پیش کیا گیا
پچھلی تعیناتی سے بچی PEM فائل کی جانچ نہ کریں؛ سروس سے وہ چین مانگیں جو وہ ابھی بھیج رہی ہے۔ openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts چین کا ہر سرٹیفکیٹ چھاپتا ہے۔ مطلوبہ بلاک محفوظ کریں اور openssl x509 -noout -subject -issuer -dates چلائیں؛ آخری notBefore اور notAfter چھاپتا ہے، اور یہی دو قدریں فیصلہ کرتی ہیں۔ Windows پر، کنکشن کا سرٹیفکیٹ ڈائیلاگ اور برآمد شدہ فائل پر certutil -dump وہی فیلڈز دکھاتے ہیں۔
ونڈو کے دونوں سرے پڑھیں، صرف آغاز نہیں۔ دو گھنٹے میں کھلنے والا سرٹیفکیٹ اور دو گھنٹے میں بند ہونے والا سرٹیفکیٹ مختلف پیغامات کے ساتھ ناکام ہوتے ہیں اور مختلف ٹیموں کو شامل کرتے ہیں۔ نوٹ کریں کہ خرابی کس سرٹیفکیٹ کا نام لیتی ہے — پتا، درمیانی یا جڑ — کیونکہ اس سے طے ہوتا ہے کہ کلائنٹ کی طرف کچھ بھی درست ہو سکتا ہے یا نہیں۔
آپ ونڈو کا انتظار کیے بغیر بھی جانچ سکتے ہیں۔ تصدیق واضح وقت قبول کرتی ہے: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem اس ٹائم اسٹیمپ پر چین کا جائزہ لیتا ہے۔ ناکامی دہرانے کے لیے موجودہ وقت کے ساتھ چلائیں، پھر سرٹیفکیٹ کے آغاز کے وقت کے ساتھ تصدیق کریں کہ ونڈو کھلنے پر وہی چین گزرتی ہے۔ RFC 5280 درستگی کا فیلڈ اور یہ قاعدہ بیان کرتا ہے کہ سرٹیفکیٹ اس سے باہر استعمال نہیں ہونا چاہیے، اور آپ کے کلائنٹ نے ابھی یہی قاعدہ نافذ کیا ہے۔
آپ کی گھڑی، یا ان کی
ڈیوائس کی گھڑی کا موازنہ سرٹیفکیٹ کے UTC آغاز سے کریں، کسی قابلِ اعتماد ذریعے سے۔ date -u لمحہ دیتا ہے، اور systemd ہوسٹ پر timedatectl status یہ بھی بتاتا ہے کہ گھڑی ہم آہنگ ہے یا نہیں۔ Windows پر، w32tm /query /status موجودہ ذریعہ اور آخری کامیاب ہم آہنگی دکھاتا ہے۔ ٹرے میں دکھایا گیا ٹائم زون نمایشی انتخاب ہے، غلط گھڑی نہیں؛ جانچنے والا UTC لمحات کا موازنہ کرتا ہے۔
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
اگر گھڑی پیچھے ہے، تو کوئی بھی سرٹیفکیٹ مواد بدلنے سے پہلے دوبارہ ہم آہنگ کریں اور دوبارہ جانچیں۔ چند منٹ یا گھنٹے غلط ڈیوائس اپنے سامنے آنے والے ہر حال میں جاری سرٹیفکیٹ کو مسترد کرتا ہے، صرف ایک سروس نہیں، اس لیے ایک سروس والی وضاحت عموماً غلط ہوتی ہے۔ اگر گھڑی درست اور ہم آہنگ ہے تو ڈیوائس کو دیکھنا بند کریں: ونڈو جاری کرنے والے کی ہے، اور اسے گزرانے کے لیے کوئی مقامی ترتیب نہیں بدلنی چاہیے۔
وہ جدول پورا فیصلہ ہے۔ گھڑی کو سرٹیفکیٹ کی توقع کے مطابق آگے پیچھے کرنا مرمت نہیں، اور وقت کی جانچ بند کرنا بھی مرمت نہیں، کیونکہ دونوں اس حالت کو چھپاتے ہیں جس نے خرابی پیدا کی۔
پتا ٹھیک دکھنے پر بھی چین کیوں ناکام ہوتی ہے
تجدید شدہ پتے اور متبادل درمیانی سرٹیفکیٹ عموماً ساتھ بھیجے جاتے ہیں، اور ہمیشہ ایک ہی لمحے نہیں پہنچتے۔ سروس ایسے درمیانی سے دستخط شدہ نیا پتا بھیج سکتی ہے جس کی اپنی ونڈو بعد میں شروع ہوتی ہے، یا نئے پتے کے نیچے پرانا درمیانی پیش کرنا جاری رکھ سکتی ہے۔ دونوں صورتوں میں چین ناکام ہوتی ہے جبکہ پتے کی اپنی تاریخیں معقول دکھتی ہیں۔
لوڈ متوازن اینڈ پوائنٹس اسے ٹوٹے سے غیر مستقل میں بدل دیتے ہیں۔ اگر دوبارہ کوشش کامیاب ہو، یا ایک نیٹ ورک چلے اور دوسرا نہ چلے، تو ترتیبات بدلنے سے پہلے نوٹ کریں کہ کس پیر نے جواب دیا اور کون سی چین بھیجی۔ openssl s_client منسلک پتہ چھاپتا ہے، اس لیے چند کوششیں ظاہر کرتی ہیں کہ ہر نوڈ وہی چین پیش کرتا ہے یا نہیں۔
تصدیق کو برقرار رکھنے والے مرمت کے راستے
گھڑی کا مسئلہ ڈیوائس پر تصدیق آن رکھتے ہوئے درست ہوتا ہے۔ سرٹیفکیٹ کا مسئلہ آپریٹر ایسے مواد سے درست کرتا ہے جو ایسی ونڈو کے لیے جاری کیا گیا ہو جس میں ابھی شامل ہے۔ کوئی کلائنٹ ترتیب ابھی-غیر درست سرٹیفکیٹ کو درست نہیں بناتی؛ وقت کی جانچ چھوڑنے والے جھنڈے تشخیص کی تصدیق کے لیے ہیں، پروڈکشن میں بھیجنے کے لیے نہیں۔
جب سرٹیفکیٹ منصوبہ بند ایکٹیویشن کے لیے تیار کیا گیا ہو، تو کٹ اوور منصوبے کی پیروی کریں۔ اسے اس کی ونڈو کھلنے پر انسٹال کریں، یا فراہم کنندہ کی دستاویزی اوورلیپ طریقہ کار استعمال کریں، بجائے اس کے کہ جلدی انسٹال کریں اور صارفین کو انتباہات کے ذریعے کلک کرنا سکھائیں۔ جن انتباہات کو لوگ نظر انداز کرنا سیکھ لیتے ہیں وہ مختصر تاخیر سے زیادہ مہنگے پڑتے ہیں۔
آخر میں، اسی طرح دوبارہ جانچیں جیسے ناکامی ہوئی تھی: نیا سیشن، وہی کلائنٹ، وہ وسیلہ جس کی آپ کو واقعی ضرورت ہے۔ TLS لائبریریاں کنکشن کی پوری عمر تک تصدیق شدہ چین کیش کر سکتی ہیں، اور دوبارہ شروع شدہ سیشن اسے لازماً دوبارہ نہیں جانچتا، اس لیے پرانا سیشن مرمت کے بعد بھی ناکام رہ سکتا ہے یا رجعت کے بعد بھی کام کر سکتا ہے۔ ویور میں کھلنے والی فائل صرف یہ ثابت کرتی ہے کہ فائل پڑھی جا سکتی ہے؛ مکمل ہینڈ شیک ثابت کرتا ہے کہ چین تصدیق ہوتی ہے۔
ٹکٹ بند کرنے سے پہلے چار چیزیں تصدیق کریں: ناکام ڈیوائس کا UTC وقت اور ہم آہنگی کی حالت، پیش کردہ چین کے ہر سرٹیفکیٹ کا notBefore اور notAfter، دوسرے کلائنٹ سے وہی چین، اور وہ نام جو خرابی سرٹیفکیٹ کو دیتی ہے۔ اگر گھڑی درست ہے اور ونڈو نہیں کھلی، تو باقی آپریٹر کا کام ہے، اور آپ کی طرف سے درست قدم تصدیق کمزور کرنے کے بجائے ونڈو کا انتظار کرنا ہے۔