Я управляю центром сертификации ADCS в Windows 2008 и знаю о рисках безопасности при выдаче сертификатов с помощью сетей SAN. Итак, я протестировал выдачу файла PKCS10 с SAN в запросе, и он выдал сертификат с SAN, когда он должен был быть заблокирован.
Конечно, я использовал команду certutil -setreg policy \ EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 (обратите внимание на минус), чтобы удалить флаг SAN, если он был, а его нет. Образ
Однако это блокирует добавление сетей SAN из дополнительных атрибутов запроса при использовании чего-то вроде этого: san:dns=webmail.domainc.com&dns=mail.domainc.com&dns=autodiscover.domainc.com
Итак, есть ли способ полностью заблокировать SAN от выданных сертификатов независимо от того, где они указаны?
Что ж, на самом деле вы уже сделали то, что должны были сделать, чтобы предотвратить ввод неавторизованного имени субъекта в сертификат посредством автоматического утверждения запроса. Пока расширение SAN аутентифицировано (встроено в CSR), можно иметь расширение SAN. Марк Хендерсон был прав в своем комментарии, вы неправильно понимаете проблему. Настоящая проблема не в SAN, а в том, как она добавляется в CSR. И разрешать SAN от неаутентифицированных атрибутов - это плохо, потому что они обрабатываются и включаются в сертификат без проверки.
Что еще вы можете сделать: требовать утверждения менеджера ЦС для всех шаблонов сертификатов, использующих значение темы из входящего запроса (не из Active Directory). Проверка значения SAN для ненадежных источников по-прежнему необходима. Нет необходимости делать это для шаблонов, которые автоматически создают тему из AD, потому что эти шаблоны полностью игнорируют информацию о теме, содержащуюся в запросе, поэтому они не затрагиваются.
