Отзыв сертификатов не работает: какой хост и куда не может достучаться

Сертификаты могут находиться в пределах срока действия, а VPN всё равно сообщает об ошибке аутентификации, и кто-то делает вывод, что сертификат отозван. Это три разных факта. Данные об отзыве должно получить то устройство, которое выполняет проверку, из точки публикации, указанной в самом сертификате. Когда это устройство не может достучаться до точки, проверка завершается неудачей по причинам, не связанным со статусом сертификата.

За путь загрузки отвечает проверяющая сторона

Начните с определения проверяющей стороны. Когда ноутбук проверяет сертификат шлюза, данные загружает ноутбук; когда шлюз проверяет клиентский сертификат, это делает шлюз. Служба аутентификации на бэкенде может добавить третьего проверяющего с собственным положением в сети. У каждого свой маршрут в интернет и своя конфигурация прокси. Доказательства, собранные на рабочей станции администратора, ничего не говорят о сервере внутри DMZ.

Запишите сертификат, проверяющую сторону, время попытки и точный код состояния, прежде чем что-либо менять.

Прочитайте точку публикации из сертификата

Сертификат указывает, где находится его статус. Читайте эти поля, а не угадывайте адрес CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

Первое расширение перечисляет точки распространения CRL, а второе перечисляет методы доступа к информации об издателе, которые могут охватывать статус OCSP и загрузку сертификата издателя. Это разные механизмы, и OCSP-ответчик не является файлом CRL. Хост публикации часто обычный веб-сервер, а не машина CA, потому что издатель в офлайне может подписать CRL, которую распространяет другой сервер. Поэтому правило межсетевого экрана, описанное как доступ к CA, слишком расплывчато для реализации или проверки.

Проверьте загрузку с устройства, которое выполняет проверку

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

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

Запуск certutil проверяет цепочку и сообщает, какие загрузки URL удались или не удались, а вызов curl проверяет один адрес публикации с того же хоста и возвращает только код состояния. Неудачная загрузка с доступного адреса указывает на проблемы с содержимым или подписью; ошибка соединения указывает на маршрутизацию, DNS или прокси. Сохраните оба результата, потому что одна удачная загрузка не доказывает, что вся цепочка пригодна. Замените пример хоста и пути на точку распространения, найденную в сертификате.

Отделите отсутствующие данные от статуса отзыва

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

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