Отозванный сертификат VPN всё ещё подключается? Проверьте применение CRL
Отозванные сертификаты продолжают подключаться, когда CRL не доходит до проверяющего. Проверьте по порядку издателя, загруженный серийный номер, поведение при перезагрузке и активные сеансы.
Вы отозвали сертификат, создали новый список, а старый профиль всё ещё поднимает туннель. Сам отзыв не сломан: CRL — это подписанное заявление о том, что серийный номер больше не действителен, и он меняет доступ только тогда, когда компонент, завершающий TLS, загрузит его, для нужного издателя, прежде чем принять решение о допуске. Именно здесь лежит большинство таких случаев, и поэтому отзыв и отказ — два разных факта.
Пройдите пять проверок ниже по порядку и остановитесь на первой, которая не выполняется, потому что каждая следующая предполагает, что предыдущие верны.
Проверьте, какой компонент принимает решение о допуске
Назовите процесс, который проверяет клиентский сертификат, потому что только он может применять список. На сервере OpenVPN это сам демон, настроенный с crl-verify. В ocserv это строка crl в ocserv.conf. В strongSwan входные данные — загруженные CRL вместе с strictcrlpolicy. Прокси или устройство, завершающее TLS перед VPN, тоже может быть настоящим проверяющим, и если это так, демон за ним никогда не видит клиентский сертификат.
WireGuard относится к другой категории. У него нет сертификатов и нет списка отзыва; пир допускается по своему открытому ключу в конфигурации, поэтому прекращение доступа означает удаление этого ключа. Если вы ищете CRL в развёртывании только с WireGuard, такого механизма там нет.
Остерегайтесь и ловушки на стороне клиента. Клиент, который отказывается подключаться, потому что ему не нравится сертификат сервера, применяет цепочку сервера, а не отзывает свои собственные учётные данные. Пользовательский сертификат отзывается только там, где этот сертификат проверяется, а это почти всегда сторона сервера.
Проверьте, для какого издателя подписан список
CRL ограничен одним издающим CA. При корневом и промежуточном CA листовые сертификаты происходят от промежуточного, поэтому значимый список — это CRL промежуточного; список корневого ничего не говорит об этих листьях. Проверяющий, направленный на неверный файл, бодро его разбирает, не находит подходящей записи и принимает всё.
Подтвердите соответствие, прежде чем трогать демон. Издатель в сертификате должен совпадать с subject списка:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateКогда оба происходят от одного CA, серийный номер, напечатанный для сертификата, — это значение, которое должно появиться в списке. Если они не совпадают, у вас неверный CRL или неверная его копия.
Срок действия относится к той же проверке. nextUpdate в прошлом делает список устаревшим, и проверяющий, который отказывает закрыто, отклонит тогда каждого клиента вместо только отозванного.
Проверьте, что серийный номер есть в копии, загруженной демоном
Отзыв записывает запись в базу CA, а повторная генерация записывает новый файл. Ни одно из действий не доходит до работающего демона, который загрузил старую копию при запуске. Выгрузите список и поищите серийный номер:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlЗатем проверьте, как ваша реализация подхватывает файл. OpenVPN читает путь, заданный в crl-verify, один раз при запуске, поэтому новый список требует перезапуска или сигнала перезапуска; та же опция, направленная на каталог, перечитывается при каждом подключении, и поэтому существует режим каталога. strongSwan должен перезагрузить свои учётные данные, например с помощью swanctl --load-creds. То, что файл на диске правильный, и то, что проверяющий его использует, — два разных факта.
Проверьте политику для отсутствующего или просроченного списка
Это решение, которое многие развёртывания никогда не принимают явно, и оно определяет, защищает ли отзыв вас или запирает всех снаружи. Fail-closed означает, что без пригодной информации об отзыве происходит отказ; fail-open означает, что проверяющий продолжает без неё. strongSwan предоставляет выбор как strictcrlpolicy. OpenVPN с crl-verify отказывается запускаться на файле, который не может прочитать или разобрать, а просроченный список проявляется как ошибка проверки TLS о просроченном CRL, а не как молчаливый допуск.
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
Какое бы направление вы ни выбрали, автоматизация важнее выбора: задача, которая перегенерирует CRL до nextUpdate, и предупреждение, когда развёрнутая копия стареет, не дают ни одной из политик стать инцидентом. Онлайн-проверка через OCSP переносит свежесть на ответчик, но действует то же правило, потому что проверяющий, не настроенный проверять ответ, ничего не меняет.
Проверьте активный сеанс, затем копии ключа
Отзыв оценивается при проверке сертификата, которая происходит при подключении и при пересогласовании. Установленный сеанс продолжает работать, пока не пересогласуется, а значение OpenVPN по умолчанию — раз в час с reneg-sec 3600. Если человек должен немедленно покинуть сеть, завершите сеанс вместе с публикацией списка, а затем подтвердите, что повторное подключение отклоняется.
Отделите учётные данные от их копий. Удаление профиля на одном ноутбуке не мешает другой копии того же закрытого ключа пройти аутентификацию; именно отзыв делает каждую копию бесполезной, и только когда предыдущие проверки выполняются. Выдайте запасному устройству собственный сертификат, чтобы один можно было отозвать, не трогая другой.
Прежде чем считать дело закрытым: проверяющий компонент определён, издатель списка совпадает с издателем листа, отозванный серийный номер находится в копии, которую демон действительно загрузил, политика для отсутствующих или просроченных списков выбрана осознанно и контролируется, а активный сеанс завершён, а не переждён. Форматы, лежащие в основе всего этого, описаны в RFC 5280.