Одно общее имя, два сертификата: список разрешённых или отзыв?

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

Начните с политики именования, которую использует сервер

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

Прочитайте конфигурацию сервера и отметьте, какой источник идентичности используется. username-as-common-name делает аутентифицированное имя пользователя действующим именем для поиска по конкретному клиенту. Без него используется общее имя субъекта из сертификата. Каким бы ни был ответ, запишите его, прежде чем трогать любой список разрешённых.

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

Проверьте, что на самом деле допускает клиента

Связанный с подходящим файлом client-config-dir предоставляет параметры для конкретного клиента; сам по себе он не является правилом допуска. Для допуска по имени нужен ccd-exclusive, который отказывает клиентам без подходящего файла. Включение этого в рабочем развёртывании отключит всех, у кого нет файла с таким именем, поэтому посчитайте файлы, прежде чем что-то переключать.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

Количество — это и есть проверка: сравните содержимое каталога с идентичностями, которые ожидаете подключить.

Затем убедитесь, что каждое имя файла точно соответствует действующей идентичности, включая регистр и пробелы. Файл для office-laptop ничего не делает для сертификата, субъект которого читается как Office-Laptop. Пробелы в конце тоже скрываются от обычного листинга, и поэтому файл, который выглядит присутствующим, остаётся непрочитанным.

Проверьте CRL, которую загружает шлюз

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

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

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

Замените, затем докажите оба исхода

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

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

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

Чего проверка имени не может никогда

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

Там, где нужен контроль на уровне сертификата, используйте механизм, который называет сертификат: записи CRL или хук проверки, который сверяет отпечаток, поддерживаемый оператором. Оба требуют обслуживания, и оба честны в отношении объекта, который проверяют. руководство OpenVPN 2.6 документирует crl-verify и допуск для конкретного клиента как отдельные параметры, именно по этой причине.

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