Применимо к: Exchange Server 2010 SP1

Последнее изменение раздела: 2010-01-25

Если использовать криптографическую терминологию, то сертификат и соответствующие закрытые ключи, создаваемые командлетом New-ExchangeCertificate, являются TLS-ключами. Командлет New-ExchangeCertificate позволяет задавать метаданные о сертификатах, так что разные службы могут использовать одни и те же сертификат и закрытый ключ. Прежде чем создать сертификаты или запросы сертификатов для служб Exchange, применяющих TLS, следует разобраться с метаданными, которые используются сертификатами для служб SSL и TLS. Эти метаданные упоминаются как «поля» в конечном сертификате.

Чтобы просмотреть поля сертификатов компьютеров на указанном компьютере, можно использовать командлет Get-ExchangeCertificate в командной консоли Exchange. Также можно использовать оснастку диспетчера сертификатов в консоли управления Microsoft.

Необходимы сведения о задачах управления, связанных с сертификатами TLS? См. раздел Управление сертификатами TLS.

Содержание

Поля, используемые сертификатами для служб TLS

Выбор сертификата

Создание сертификатов TLS

Ссылки

Поля, используемые сертификатами для служб TLS

Если для создания запроса сертификата от стороннего центра сертификации или другого центра сертификации инфраструктуры открытых ключей используется командлет New-ExchangeCertificate, убедитесь, что выполнена проверка полей сертификата и формата сертификата, которые запрашиваются центром сертификации.

В этом разделе описываются наиболее важные поля сертификатов и предоставляются некоторые рекомендации по созданию сертификатов и запросов сертификатов.

Имя субъекта

«Имя субъекта» TLS-сертификата — это поле, используемое службами, взаимодействующими с DNS. Поле «Имя субъекта» привязывает сертификат к определенному имени сервера или домена.

Имя субъекта — это различающееся имя X.500, которое состоит из одного или нескольких относительных различающихся имен, которые также упоминаются как RDN (relative distinguished names). В следующей таблице перечисляются относительные различающиеся имена, часто используемые для идентификации организаций или объектов серверов.

Имя Аббревиатура Тип Макс. размер Частота Макс.\рекомендуемая в сертификате\запросе Порядок в субъекте

Страна/регион

C

ASCII

2

1\1

1

Компонент домена

DC

ASCII

255

Несколько

1

Область или район

S

Юникод

128

1

2

Местность

L

Юникод

128

1

3

Организация

O

Юникод

64

1\1

4

Подразделение

OU

Юникод

64

Несколько\Несколько

5

Общее имя

CN

Юникод

64

Несколько\1

6

Коды страны/региона являются кодами ISO 3166-1. Дополнительные сведения см. по ссылке Английские названия стран и элементы кода.

«Компонент домена» и «Страна/регион» согласно соглашению являются взаимно исключающими. Рекомендуется ссылаться на имя по стране/региону или по имени, существующему в службе доменных имен. Также следует иметь в ввиду, что максимальный размер компонента домена (255 символов) является суммой всех значений компонента домена.

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

Указание относительных различающихся имен

При создании запросов сертификата с помощью командлета New-ExchangeCertificate имена субъектов представляются в виде одного параметра, состоящего из последовательности имен, разделенных запятыми. Каждое имя идентифицируется аббревиатурой относительного различающегося имени. Например, следующее имя субъекта представляется как «Страна/регион» = US, «Организация» = Contoso Corp и «Общее имя» = mail1.contoso.com:

Скопировать код 
-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

Другие имена субъектов, которые могут представлять тот же самый сервер, приводятся в следующих примерах:

Скопировать код 
-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

При наличии зарегистрированного DNS-имени, которое применяется для отправки SMTP-почты, рекомендуется использовать соглашение по компонентам доменов и DNS-имя для имени сертификата, например DC=contoso, DC=com, CN=mail1.contoso.com.

Однако при создании запроса сертификата для поставщика центра сертификации необходимо ясно понимать требования центра сертификации, предъявляемые к полю «Имя субъекта», и потребности своей уникальной инфраструктуры открытого ключа. В некоторых случаях, возможно, потребуется использовать код страны/региона («C»). В этом случае необходимо зарегистрировать относительное различающееся имя в центре регистрации X.500.

Международные имена субъектов

Для имен субъектов, содержащих символы, отличные от ASCII-символов, можно ввести параметр SubjectName в качестве различающегося имени, заключенного в кавычки, как показано ниже:

-SubjectName "C=ES,O=Diversion de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

Имена субъектов и имена доменов

По соглашению общее имя может содержать полное доменное имя (FQDN). Хотя этот способ широко практикуется, необходимо обратить внимание на следующие две проблемы.

Во-первых, максимальный размер поля общего имени равен 64 символам. Это меньше, чем максимальный размер полного доменного имени. Поэтому при использовании имени FQDN, содержащего более 64 символов, необходимо поместить доменное имя в поле «Дополнительное имя субъекта». Параметр DomainName — это параметр, сопоставленный с дополнительным именем субъекта в конечном сертификате.

Во-вторых, полное доменное имя ограничено подмножеством набора символов ASCII. Однако общее имя (CN) поддерживает Юникод. Поэтому можно создать действительный сертификат с общим именем, которое выглядит как DNS-имя, но является недопустимым DNS-именем. Программное обеспечение, ищущее полное доменное имя в общем имени сертификата, не вернет правильный результат, если общее имя содержит символы, отличные от ASCII-символов. Например, если создать сертификат с именем субъекта, где CN=mail.microsoft.com, данное имя не будет считаться полным доменным именем, поскольку оно содержит символ Юникода — «i» с диакритическим знаком (x00ef). Общее имя в Юникоде легко спутать с именем FQDN из-за незначительных различий между символом «i» с диакритическим знаком (x00ef) и символом «i» в ASCII (x0069). Задача сертификата Exchange не требует, чтобы общее имя субъекта было допустимым именем FQDN. По умолчанию это означает, что командлет включает полное доменное имя сервера в качестве общего имени по умолчанию.

Имена доменов в сертификатах

Для протокола TLS сертификаты должны содержать DNS-имена, так как TLS является протоколом, работающим на основе службы DNS. Клиенты проверяют, чтобы DNS-имя сервера, к которому они подключаются с помощью DNS-имени, позволяло подключиться к требуемому серверу. Это верно для веб-браузеров, которые подключаются к веб-сайту по протоколу HTTPS, и для SMTP-серверов, передающих электронную почту через Интернет или интранет.

Одиночный сервер может поддерживать несколько DNS-имен по следующим причинам:

  • SMTP-сервер поддерживает несколько принятых доменов.

  • Клиент может получать доступ к серверу электронной почты по имени сервера, по имени домена, по локальному имени полного доменного имени или по имени, определяемому по сбалансированной нагрузке.

Если после установки TLS-подключения клиент обнаружит искомое имя, клиент игнорирует другие имена в сертификате. Несколько имен домена и сервера могут добавляться в поле дополнительного имени субъекта TLS-сертификата. Сертификат, содержащий несколько дополнительных имен субъекта, можно создать с помощью параметра DomainName командлета New-ExchangeCertificate. Параметр DomainName является многозначным, поэтому может принимать несколько имен.

Сертификаты X.509 могут содержать в расширении сертификата «Дополнительное имя субъекта» (SubjectAltName) одно или несколько DNS-имен либо вообще не содержать DNS-имен. DNS-имена в расширении SubjectAltName точно соблюдают ограничения, существующие для DNS-имен. Они не должны содержать более 255 символов, и, кроме того, должны состоять только из символов A-Z, a-z, 0-9 и тире (-).

Логика сопоставления имен для функции безопасности домена

Логика сопоставления имен сертификатов для функции безопасности домена проверяет соответствие имени домена в полученному сертификате имени домена, в который отправляется почта. В качестве примера рассмотрим имя FQDN домена получателя woodgrovebank.com. Логика сопоставления имен сертификатов выполняет поиск всех DNS-имен в сертификатах, и если одно из DNS-имен совпадает, сертификат считается соответствующим указанному домену.

В данном примере логика сопоставления имен сертификатов принимает сертификат с полностью совпадающим именем домена, таким как woodgrovebank.com. Кроме того, в сертификатах могут использоваться подстановочные знаки для имен доменов, поэтому сертификат с DNS-именем *.woodgrovebank.com считается соответствующим. Дополнительные сведения об именах домена с подстановочными знаками в подразделе «Имена домена с подстановочными знаками» ниже в данном разделе.

Логика сопоставления имен сертификатов также выполняет поиск в DNS глубиной в один узел. Поэтому mail1.woodgrovebank.com также считается соответствующим woodgrovebank.com. Тем не менее, DNS-имена с глубиной более двух узлов не принимаются. Поэтому, например, mail1.us.woodgrovebank.com не будет считаться соответствующим woodgrovebank.com.

Рекомендации по доменным именам для SMTP-серверов в Интернете

При создании сертификата или запроса сертификата для пограничного транспортного сервера, осуществляющего TLS-взаимодействие по протоколу SMTP через Интернет, в запрос необходимо включить следующий набор имен доменов:

  • Полное доменное имя сервера в Интернете — это имя может отличаться от внутреннего полного доменного имени, которое используется между пограничными транспортными серверами и транспортными серверами-концентраторами, и должно соответствовать записи «А», публикуемой на общедоступном DNS-сервере в Интернете. Это имя необходимо вводить как общее имя в параметр SubjectName командлета New-ExchangeCertificate.

  • Все имена обслуживаемых доменов организации   Чтобы заполнить поле «Дополнительное имя субъекта» для конечного сертификата, используйте параметр IncludeAcceptedDomains командлета New-ExchangeCertificate.

  • Имя FQDN соединителя, если для него не используется любой из предыдущих элементов   Чтобы заполнить поле «Дополнительное имя субъекта» для конечного сертификата, используйте параметр DomainName командлета New-ExchangeCertificate.

Доменные имена с подстановочными знаками

Доменные имена с подстановочными знаками относятся к специальному типу доменных имен, представляющих несколько подчиненных доменов. Доменные имена с подстановочными знаками помогают упростить сертификаты, так как одно доменное имя с подстановочными знаками представляет все подчиненные домены этого домена. Эти имена представляются символом звездочки ( * ) в DNS-узле. Например, *.contoso.com представляет contoso.com и все поддомены для contoso.com. Если при создании сертификата или запроса сертификата для всех принятых доменов использовать подстановочный знак, можно существенно упростить запрос.

Выбор сертификата

Exchange выполняет различные процессы выбора сертификата в зависимости от типа SMTP-подключения.

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

Когда узел или клиент SMTP подключается к пограничному транспортному серверу или транспортному серверу-концентратору, используется процесс выбора сертификата STARTTLS. Дополнительные сведения см. в разделе Выбор входящих сертификатов STARTTLS.

Создание сертификатов TLS

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

Ссылки

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

  • Инфраструктура открытых ключей Windows Server 2008 и безопасность сертификатов

  • Housley, Russ and Tim Polk (Хаусли, Русс и Тим Полк). Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure (Планирование инфраструктуры открытого ключа: руководство по развертыванию инфраструктуры открытого ключа). New York (Нью-Йорк): John Wiley & Son, Inc., 2001.

  • Брюс Шнайер (Bruce Schneier). Applied Cryptography: Protocols, Algorithms, and Source Code in C (Прикладная криптография: протоколы, алгоритмы и исходный код на Си), 2nd Edition (2-е издание). New York (Нью-Йорк): John Wiley & Son, Inc., 1996.