Contents of this directory is archived and no longer updated.

Как правильно задавать имя сертификата при использовании расширения Subject Alternative Name (SAN)

Достаточно часто администраторы занимаются выпуском сертификатов с использованием нескольких имён. Например, когда нужно привязать один сертификат к нескольким именам: mail.company.com и owa.compny.com. Однако поле Subject может содержать только одно имя. Для разрешения этой проблемы используется расширение Subject Alternative Name (SAN). В этом расширении вы можете использовать сколько угодно дополнительных имён для сертификата.

Но как правильно же оформить несколько имён в сертификате на примере mail.company.com и owa.company.com? Здесь варианта всего 2:

  • Использовать поле Subject и расширение SAN

Данный способ используется чаще для внешних сертификатов. Поле Subject заполняется следующим образом (красным выделены обязательные компоненты):

CN = mail.company.com
OU = <название подразделения>
OU = <ещё какое-то название подразделения>
O = <название организации>
L = <местоположение компании>
C = <код страны, где расположена компания>

Т.е. включается основное имя сертификата (по правде говоря, при использовании SAN, понятие основного имени отсутствует, т.к. все имена считаются равноценными. Здесь следует указывать имя, которое будет использоваться чаще всего приложениями, неподдерживающими расширение SAN) и опционально можно задать дополнительные DN суффиксы, отражающие принадлежность сертификата. И расширение SAN заполняется следующим образом:

DNS Name=mail.company.com
DNS Name=owa.company.com

Как видите, имя из Subject продублировано в SAN. Дело в том, что если в сертификате есть расширение SAN и приложение умеет его обрабатывать, приложение как правило настраивается только на проверку расширения SAN и в Subject они не заглядывают. Но это не всегда так. Иногда приложение смотрит и в Subject и в SAN. В таком случае имена дублировать не обязательно. Но в целях обеспечения совместимости следует ВСЕГДА дублировать имя из Subject в расширении SAN.

  • Использовать только расширение SAN

Этот способ редко применяется во внешних сертификатах, а только внутренних. В этом случае поле Subject не заполняется совсем и оставляется пустым. А расширение SAN будет включать все необходимые имена:

DNS Name=mail.company.com
DNS Name=owa.company.com

Такая форма заполнения поддерживается в Internet PKI и описана в RFC 5280. Согласно этому RFC, если поле Subject не определено (пусто), имя для сертификата выбирается из расширения SAN, а само расширение помечается как критичное (см. RFC 5280 §4.2.1.6). Вот примерные пруфпики, как это выглядит в жизни:

General tab view

на вкладке General имя формируется либо из первого имени в расширении SAN или из имени используемого конкретным приложением (например, при просмотре из браузера) и котрое перечислено в расширении SAN.

Empty Subject field

Здесь продемонстрировано пустое поле Subject.

Critical SAN Extension

И перечисление необходимых имён в расширении SAN. Критичность расширения определяется по наличию жёлтого треугольничка и восклицательного знака.

На заметку: что такое критичное расширение (critical extension)? Это просто расширение, которое приложение должно проверить в обязательном порядке. Если приложение видит такое расширение, приложение должно уметь его обработать и понять значение в этом расширении. Если приложение не знает, что делать с этим расширением или приложение не может разобрать значение этого расширения, приложение обязано отклонить данный сертификат. Более подробно о порядке поведения приложения.

Примечание: хоть и заявляется, что приложение должно отклонить сертификат, если значение расширения непонятно, это не в полной мере относится к расширению SAN. Приложение не обязано поддерживать все формы SAN, а может поддерживать только некоторые формы, например, только DNS Name. Но если поддерживаемая форма не может быть распознана, сертификат должен быть отклонён.

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

Какой способ из двух выбрать? А какой считаете более приемлемым. Если это сертификат внешнего веб-сервера, целесообразно использовать первый вариант, поскольку при помощи DN суффиксов можно конкретизировать принадлежность сертификата к вашей компании. А так же если предполагается доступ из приложений неподдерживающих расширение SAN. Это не обязательно компьютерные приложения, это могут быть приложения мобильных устройств. В целях избежания чрезмерного пиара VeriSign'a в моём бложике, представляю образцово-показательный сертификат выполненный первым способом на сайте Thawte: https://www.thawte.com/

Для использования внутри организации можно использовать и второй вариант, с пустым Subject. Например, для логонных сертификатов смарт-карт. Контроллеры домена вообще не смотрят на Subject логонного сертификата, а смотрят только в SAN на предмет наличия UPN в расширении.

Что бы почитать?

Comments:

binGO
binGO 21.09.2010 14:05 (GMT+3)

Привет! Можно ли добавить расширение SAN в сертификаты, выпускаемые изолированным CA ?

Vadims Podāns
Vadims Podāns 22.09.2010 12:56 (GMT+3)

Да, можно. Для этого сначала нужно включить поддержку SAN: certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 т.е. принципиальной разницы здесь не будет. Ну и запрос, естественно, должен содержать расширение SAN.

binGO
binGO 24.09.2010 11:47 (GMT+3)

Понятно. А можно ли такой запрос создать в самом изолированном СА, ну например через web-интерфейс (на CA поднят IIS) - "создать запрос к данному СА" ? Команду certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 выполнил. Пробую создать запрос, но в web-диалоге нет поля san, всё осталось как было.

Vadims Podāns
Vadims Podāns 24.09.2010 12:25 (GMT+3)

http://technet.microsoft.com/en-us/library/cc740063(WS.10).aspx

binGO
binGO 26.09.2010 14:40 (GMT+3)

Почитал статью. Кое-что не понятно, например, там сказано, что для обеспечения работы с пользовательским расширением (custom extension) оно должно передаваться по объектному идентификатору этого расширения. Делается это командой: certutil-setreg policy\EnableRequestExtensionList + <объектный идентификатор для расширения, которое будет добавлено>. Под расширением (extension) я понимаю «поля» сертификатов, например поле\расширение SAN. Но что такое объектный идентификатор расширения? Причём, согласно статьи, это определяется организацией.

Vadims Podāns
Vadims Podāns 27.09.2010 11:16 (GMT+3)

> Но что такое объектный идентификатор расширения? это уникальный идентификатор расширения. > Причём, согласно статьи, это определяется организацией не совсем так. SAN является стандартным расширением и используется в Internet PKI, поэтому он не может определяться организацией и имеет фиксированное значение.

binGO
binGO 27.09.2010 13:31 (GMT+3)

>>это уникальный идентификатор расширения. Понятно, так и предположил. Где-нибудь можно посмотреть их? Я так понимаю это должно быть стандартизировано, какое поле с каким ID. На форуме КриптоПро увидел - SAN - 2.5.29.17 Это правильно? >>не совсем так. SAN является стандартным расширением и используется в Internet PKI,...... Видимо неправильно перевёл. Отсюда и конфликт - что речь идёт про стандартное расширение, но почему-то определяются они организацией. Вот абзац: To enable custom extension passing by using the object identifier of the custom extension defined by the organization, use the following command: certutil -setreg policy\EnableRequestExtensionList +< object identifier of extension to be added> Перевёл так: Что бы обеспечить (дать возможность) пользовательским расширениям передаваться (видимо в certificate request) для использования по объектному идентификатору этих расширений, определённых организацией, выполните следующую команду: certutil-setreg policy\EnableRequestExtensionList + <объектный идентификатор для расширения, которое будет добавлено> P.S. Написал и похоже понял где ошибся. Речь идёт о том что организация определяет наличие в сертификате тех или иных расширений, ID которых будут передаваться в запросе для обработки, а не сами ID.

Vadims Podāns
Vadims Podāns 27.09.2010 21:30 (GMT+3)

> SAN - 2.5.29.17 Это правильно? да, это стандартный OID: http://www.alvestrand.no/objectid/2.5.29.17.html > Видимо неправильно перевёл не пользуйтесь онлайн транслаторами. Эта часть статьи относится к тому, что организация может определять свои собственные OID'ы, которые будут распознаваться только в пределах самой организации (до тех пор, пока этот OID не станет стандартом в internet PKI). Более подробно рекомендую почитать вот: http://www.sysadmins.lv/PermaLink,guid,58b58ace-a862-4a7b-a74f-b6d4993a28b5.aspx

binGO
binGO 27.09.2010 23:24 (GMT+3)

>>http://www.sysadmins.lv/PermaLink,guid,58b58ace-a862-4a7b-a74f-b6d4993a28b5.aspx Отличная статья. Я её не видел до этого. Так. Промежуточное уточнение. Команда: "certutil -setreg policy\EnableRequestExtensionList +2.5.29.17" - разрешает включение расширения SAN в издаваемый сертификат. Команда: "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" - добавляет в реестр флаг разрешающий обработку расширения SAN в запросе. Правильно мыслю?

Vadims Podāns
Vadims Podāns 29.09.2010 20:49 (GMT+3)

Вообще да. Но "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" заменяет первую команду.

binGO
binGO 29.09.2010 23:45 (GMT+3)

О! А я ошибочно думал у них несколько разное назначение. А как сформировать и применить запрос, содержащий расширение SAN ? Что-то не получается у меня. Из первой статьи следует (насколько я понял), что надо поправить файл policy.inf, внеся в него строчку SAN:dns=sample.bar.com (само имя взято естественно как пример). Но можно ли дальше использовать для запроса Web Enrollment Pages или только policy.inf с CertReq.exe ?

Vadims Podāns
Vadims Podāns 30.09.2010 00:06 (GMT+3)

конечно, значения у них разные. Просто второе накладывается на первое. > А как сформировать и применить запрос, содержащий расширение SAN ? забанили в гугле? http://support.microsoft.com/kb/931351

Сардор
Сардор 25.01.2012 11:40 (GMT+3)

Вадим, Здравствуйте! Подскажите плиз, как вы описывали с своих статьях, можно активировать SAN при помощи "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2", но не рекомендуется включать флаг, просто есть проблема, когда активируете, powershell выводит запись: Certutil: -setreg command failed: 0x8007000d, Certutil: The data is invalid, как быть?

Vadims Podāns
Vadims Podāns 25.01.2012 13:28 (GMT+3)

во-первых, вам скорее всего не надо включать этот флаг, это раз. Второе, лучше её запускать в CMD, потому что интерпретатор PowerShell ломается на знаке "+"

Сардор
Сардор 25.01.2012 14:38 (GMT+3)

Я вас понял, но в командой строке было тоже самое.... Планируется развертывания exchаnge 2010 на dc2, и на dc1 я хотел активировать SAN, без этих Флагов, обязательно ли активировать на ваш взгляд и не повлияет это ни на что?

Vadims Podāns
Vadims Podāns 25.01.2012 16:44 (GMT+3)

Хм, а на этом сервере установлена служба CA?

Сардор
Сардор 25.01.2012 16:47 (GMT+3)

Да, конечно, кстати, влияет на это, то, что при установке Центра Сертификации отмечено только служба Certification Authority и Certification Authority Web Enrollment, других не нужно выбирать?

Comments are closed.