Сертифікат 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 кожного сертифіката в пред'явленому ланцюжку, той самий ланцюжок від другого клієнта та ім'я, яке помилка дає сертифікату. Якщо годинник правильний, а вікно ще не відкрилося, решта — робота оператора, і правильний крок з вашого боку — чекати на вікно, а не послаблювати перевірку.