Что ваш VPN-клиент проверяет, прежде чем довериться сертификату

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

Прочитайте диалог, прежде чем править профиль

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

Повысьте уровень журналирования, прежде чем что-либо менять. OpenVPN сообщает об ошибке проверки вокруг рукопожатия, если запустить его с --verb 4, а strongSwan записывает свои решения об идентичности и цепочке в журнал charon. Затем убедитесь, какой именно сертификат вы изучаете, потому что люди обычно проверяют файл на диске, тогда как профиль встраивает более старую копию. Когда профиль встраивает блоки PEM, проверяется именно встроенный сертификат.

Удостоверяющий центр подписывает идентичности, а не разрешения

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

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

Восстановите путь, который пытается построить клиент

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

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Нулевой код выхода означает, что путь построен из этих файлов; ошибка называет сертификат, до которого не удалось дойти. Если openssl verify успешен, а клиент всё ещё отказывает, разница в том, что сервер фактически отправляет, или в том, какой файл доверия загружает профиль. В OpenVPN промежуточные сертификаты могут идти вместе с файлом сертификата сервера или подаваться отдельно с --extra-certs, а пакет с двумя корнями под одним именем субъекта отправит одного из ваших клиентов в неверную ветвь.

Имя и назначение — отдельные шлюзы

Построение цепочки никогда не спрашивает, ваше ли это имя. OpenVPN проверяет его только когда профиль задаёт --verify-x509-name, а старая привычка сопоставлять только общее имя ломается на сертификатах, чьи идентичности живут в subjectAltName. Развёртывания IKEv2 сопоставляют настроенную идентичность с записями SAN или с отличительным именем, в зависимости от клиента, а значение с подстановочным знаком или %any тихо отключает сравнение, которое вы считали имеющимся.

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

Отзыв работает только если кто-то его настроил

CRL или ответ OCSP не проверяются автоматически. На сервере OpenVPN клиентские сертификаты сверяются со списком только когда --crl-verify указывает на него. Проверка сертификата сервера на стороне клиента зависит от реализации и часто отсутствует. strongSwan нуждается в своём плагине отзыва и политике, прежде чем смотреть на CRL для узла.

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

Порядок ремонта, при котором проверка остаётся включённой

Отсортируйте по симптому, прежде чем трогать файлы, потому что каждая строка таблицы отправляет вас к другому объекту.

Пройдите список за один проход: подтвердите файл, который загружает профиль, постройте путь сами, проверьте, что сервер отправляет промежуточный сертификат, сравните часы, прочитайте SAN, прочитайте EKU, затем переподключитесь и наблюдайте, как та же строка журнала исчезает. Если устройству вообще нельзя дать CA, привязка — честная альтернатива, потому что OpenVPN 2.6 принимает --peer-fingerprint и сужает доверие до одного ключа вместо удаления проверки. RFC 5280 — справочник о значении каждого из этих полей.