گواهی 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 هر گواهی در زنجیره ارائه‌شده، همان زنجیره از کلاینت دوم، و نامی که خطا به گواهی می‌دهد. اگر ساعت درست است و پنجره باز نشده، بقیه کار اپراتور است و حرکت درست از سمت شما انتظار برای پنجره است، نه تضعیف بررسی.