Один CSR — ещё не регистрация: что должен проверить CA для VPN

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

Две модели регистрации стоит сравнивать по тому, что они связывают, а не по тому, на каком протоколе они говорят.

Запрос заявляет имя, но не доказывает его

Читайте запрос по тому, что в нём действительно есть: открытый ключ, выбранный заявителем subject и собственная подпись над обоими. Ничто в этой структуре не ссылается на ваш инвентарь, каталог учётных записей или процесс согласования. Subject вроде cn=finance-laptop — это строка, которую кто-то набрал. Пока процесс выдачи не сверит эту строку с записью, которой доверяет, сертификат остаётся утверждением с приложенной подписью. Это различие и есть вся причина существования процесса регистрации.

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

Сравните модели по тому, что они связывают

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

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

Выбирайте модель по числу ожидаемых регистраций и по сменяемости устройств. Несколько серверов в год переживут ручную проверку с письменным контрольным списком. Парк ноутбуков — нет.

Фиксируйте жизненный цикл с первой выдачи

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

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

Проверьте выданный сертификат, затем доступ

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

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