شهادة 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 اللحظة، ويبلغك timedatectl status على مضيف systemd أيضاً ما إذا كانت الساعة متزامنة. على 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 لكل شهادة في السلسلة المقدَّمة، والسلسلة نفسها من عميل ثانٍ، والاسم الذي يضعه الخطأ على الشهادة. إذا كانت الساعة صحيحة والنافذة لم تُفتح بعد، فالباقي عمل المشغّل، والخطوة الصحيحة من جانبك هي انتظار النافذة بدلاً من إضعاف الفحص.