Новые входы в VPN не проходят при действующих сертификатах: проверьте CRL

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

Разделение двух расписаний и есть весь диагноз, и оно меняет то, каким должно быть исправление.

Два часа, и только один из них — сертификат

Сертификат несёт окно действия. Список отзыва сертификатов несёт своё окно, а также издателя и подпись, и проверяющие отказываются доверять списку, время следующего обновления которого прошло. Когда это происходит, клиент предъявляет полностью действующий сертификат, а сервер всё равно разрывает соединение с сообщением о списке. Пользователи читают это сообщение как «сертификат истёк», из-за чего запрос на продление уходит не туда.

У двух объектов и владельцы разные: сертификат приходит от CA, которая его выпустила, а список генерируется по расписанию тем, кто эксплуатирует эту CA. Пользователь не может его обновить, а перевыпуск сертификатов не может его продлить.

Прочитайте список, который служба действительно загружает

Начните с работающей конфигурации, а не с файла, который вы ожидаете. Путь crl-verify может быть абсолютным, относительным к профилю или копией, запечённой в образ, и проверяющий читает именно эту копию. Осмотрите её на месте с помощью openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate и сравните даты с часами сервера.

Затем подтвердите, что файл действительно используется: проверьте его подпись с помощью openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, которая сообщает результат проверки, а не молча печатает поля. Список, подписанный другой CA, или устаревшая копия, оставленная во втором каталоге, терпит неудачу точно так же, как просроченный.

Перегенерируйте из базы отзыва, а не с нуля

Новый список должен происходить из текущей базы отзыва CA через утверждённый процесс подписи. Генерация пустого списка или перегенерация из старой резервной копии индекса молча снимает отзыв с каждой идентичности, добавленной после этой копии. Это превращает сбой входа в регрессию безопасности, и никто этого не замечает, потому что симптом исчезает.

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

Развёртывайте там, куда смотрит проверяющий

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

Если несколько служб проверяют клиентов, разверните у каждой из них. Обновление одной конечной точки и оставление другой со старой копией даёт сбой, который проявляется только у пользователей, попадающих на вторую. Держите короткий список таких конечных точек в том же runbook. После развёртывания проверьте сообщённую дату списка у каждой из них, а не предполагайте, что копия дошла.

Сделайте следующий срок видимым до того, как он пройдёт

Более длинный интервал публикации снижает частоту этого инцидента, не создавая процесса. Выберите интервал из политики оператора, затем настройте оповещение по полю следующего обновления развёрнутого списка с достаточным запасом времени для перегенерации и развёртывания. Оповещайте по развёрнутой копии, а не по хосту CA, потому что терпит неудачу именно развёрнутая копия.

После развёртывания проверьте оба направления: разрешённый пользователь подключается, а известная отозванная идентичность по-прежнему не проходит. Вторая проверка — та, что ловит неполную перегенерацию, и для неё нужна одна команда против тестового профиля, который вы держите именно для этой цели.