Вы открываете клиент, выбираете профиль, которым пользуетесь месяцами, и он останавливается с сообщением "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 seeMost likely readingNext step
Clock behind, one device affectedLocal time faultResync time, keep validation on, retest
Clock correct, window opens soonCertificate staged earlyWait for the window or follow the cutover plan
Clock correct, intermediate not yet validChain material mismatchOperator replaces the intermediate
Some peers pass, others do notInconsistent nodesRecord each peer's chain before changing anything

Если часы отстают, синхронизируйте их заново и повторите проверку, прежде чем менять любой материал сертификата. Устройство, ошибающееся на минуты или часы, отвергает каждый недавно выпущенный сертификат, который встречает, а не только одну службу, поэтому объяснение через одну службу обычно неверно. Если часы верны и синхронизированы, перестаньте смотреть на устройство: окно принадлежит издателю, и никакую локальную настройку не следует менять, чтобы оно прошло.

Эта таблица — всё решение. Переводить часы на то, что ожидает сертификат, — не ремонт, и отключать проверки времени — тоже, потому что и то и другое скрывает состояние, породившее ошибку.

Почему цепочка сбоит, пока лист выглядит нормально

Обновлённые листы и заменяющие промежуточные сертификаты обычно поставляются вместе, и они не всегда оказываются в один момент. Служба может отправить новый лист, подписанный промежуточным, чьё собственное окно начинается позже, или продолжать отдавать более старый промежуточный под свежим листом. Так или иначе цепочка сбоит, пока даты самого листа выглядят разумно.

Балансируемые конечные точки превращают это из сломанного в несогласованное. Если повторная попытка успешна или одна сеть работает, а другая нет, запишите, какой узел ответил и какую цепочку он отправил, прежде чем менять настройки. openssl s_client печатает подключённый адрес, поэтому несколько попыток показывают, отдаёт ли каждый узел одну и ту же цепочку.

Пути ремонта, сохраняющие проверку

Проблема часов исправляется на устройстве при включённой проверке. Проблему сертификата исправляет оператор материалом, выпущенным для окна, которое уже включает сейчас. Никакая настройка клиента не делает ещё не действительный сертификат действительным; флаги, пропускающие проверки времени, существуют, чтобы подтвердить диагноз, а не чтобы их внедрять.

Когда сертификат подготовлен к плановой активации, следуйте плану перехода. Установите его, когда откроется его окно, или используйте процедуру перекрытия, документированную поставщиком, вместо того чтобы устанавливать заранее и учить пользователей прощёлкивать предупреждения. Предупреждения, которые люди учатся игнорировать, стоят дороже короткой задержки.

Наконец, повторите проверку так, как произошёл сбой: новая сессия, тот же клиент, ресурс, который вам действительно нужен. Библиотеки TLS могут кэшировать проверенную цепочку на всё время жизни соединения, а возобновлённая сессия не обязательно проверяет её снова, поэтому старая сессия может продолжать сбоить после исправления или продолжать работать после регрессии. Файл, который открывается в просмотрщике, доказывает лишь то, что файл читается; завершённое рукопожатие доказывает, что цепочка проверяется.

Прежде чем закрыть заявку, подтвердите четыре вещи: время UTC и состояние синхронизации сбоящего устройства, значения notBefore и notAfter каждого сертификата в предъявленной цепочке, ту же цепочку от второго клиента и имя, которое ошибка даёт сертификату. Если часы верны, а окно ещё не открылось, остальное — работа оператора, и правильный шаг с вашей стороны — ждать окно, а не ослаблять проверку.

Похожие статьи