Проектирование шаблонов AD CS для ролей VPN-шлюза и клиента

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

Напишите таблицу ролей до открытия консоли шаблонов

Две роли, два назначения. Шлюз доказывает идентичность службы, поэтому его сертификату нужны Server Authentication (1.3.6.1.5.5.7.3.1), использование ключа для цифровой подписи и шифрования ключа, а также имя узла, к которому подключаются клиенты, в альтернативном имени субъекта. Клиентам, проходящим проверку подлинности по сертификатам, нужны Client Authentication (1.3.6.1.5.5.7.3.2) и идентичность, совпадающая с тем, что шлюз ожидает при проверке второй стороны. Пользовательский и компьютерный сертификаты не взаимозаменяемы, потому что находятся в разных хранилищах и используются разными процессами.

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

Копируйте шаблон, а не правьте общий

Начните с шаблона с примерно правильным назначением, например RAS and IAS Server для шлюза или Computer для устройств, присоединённых к домену, затем скопируйте его и дайте копии имя, говорящее, для чего она. Расширение шаблона, который уже используют другие службы, — это изменение, которое через шесть недель ломает что-то несвязанное. В копии задайте политики применения по назначению из таблицы ролей, сохраните согласованность использования ключа, выберите алгоритм и длину ключа, которые принимают ваши шлюзы, и пометьте закрытый ключ как неэкспортируемый, если только устройству не нужно экспортировать его для переноса.

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

Решите, откуда берётся субъект

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

Windows IKEv2 здесь строг. Сертификат шлюза сопоставляется с именем, которое настроил клиент, поэтому имя DNS должно присутствовать там, где клиент его ищет, обычно как запись dNSName в альтернативном имени субъекта. Отключение проверки имени или назначения, чтобы заработал несоответствующий сертификат, убирает проверку, которая поймала бы несоответствие в производстве.

Опубликуйте шаблон, затем сузьте разрешения

Создание объекта шаблона в AD DS и его публикация на выдающем CA — отдельные операции, выполняемые в разных консолях. Опубликуйте копию из консоли Certification Authority в разделе Certificate Templates, затем проверьте из командной строки, что CA теперь предлагает его:

certutil -CATemplates
certutil -TCAInfo

Далее разрешения. Дайте Read и Enroll группам, которые должны его запрашивать, и ничего больше, сохраните собственный доступ CA на чтение и давайте Autoenroll только там, где автоматическая регистрация предусмотрена и подкреплена политикой развёртывания, которая заставляет её работать. Флажок в шаблоне сам по себе ничего не регистрирует, а опубликованный шаблон без разрешения на регистрацию создаёт портал, который перечисляет сертификат и затем отклоняет запрос.

Зарегистрируйте один пилот у реального потребителя

Запросите сертификат в том контексте, который будет его использовать, затем изучите, что вернулось, вместо того чтобы доверять имени файла. Пользовательский сертификат попадает в хранилище текущего пользователя, а компьютерный — в хранилище локального компьютера, и MMC показывает оба, поэтому регистрация, которая “сработала”, может остаться невидимой для службы VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Прочитайте дамп на предмет субъекта, альтернативных имён, расширенного использования ключа и цепочки. Для шлюза, не работающего под Windows, подайте запрос через поддерживаемый рабочий процесс, а не предполагайте, что автоматическая регистрация домена до него дойдёт, и подтвердите, что экспортированный формат — тот, который потребитель импортирует вместе со своим соответствующим закрытым ключом. Наконец, держите доверие и авторизацию отдельно: VPN всё ещё должен решать, какие пользователи или устройства получают доступ к каким ресурсам, а отзыв убирает доступ только если шлюз вообще проверяет отзыв. Руководство Microsoft по управлению шаблонами сертификатов охватывает консоль шаблонов, разрешения и отдельный шаг публикации.