Создание сертификата или запроса сертификата для TLS

Статья
09/30/2014

Применимо к: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Последнее изменение раздела: 2011-11-04

В этом разделе описывается создание сертификата или запроса сертификата X.509 Transport Layer Security (TLS) с помощью командлета ExchangeCertificate в командной консоли Exchange.

Важно!
Перед чтением этого раздела ознакомьтесь с общими принципами использования сертификатов в Microsoft Exchange Server 2007. См. раздел Использование сертификатов в Exchange Server 2007.

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

Чтобы просмотреть поля сертификатов компьютеров на заданном компьютере, можно воспользоваться командлетом Get-ExchangeCertificate в командной консоли Exchange. Или можно использовать оснастку диспетчера сертификатов в консоли управления (MMC, Microsoft Management Console). Дополнительные сведения об использовании оснастки диспетчера сертификатов см. в разделе Инструкции по добавлению диспетчера сертификатов в консоль управления (MMC).

Общие сведения о полях, используемых сертификатами для служб 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. Дополнительные сведения см. по ссылке Английские названия стран и элементы кода.

Примечание.
UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

«Компонент домена» и «Страна/регион» согласно соглашению являются взаимно исключающими. Рекомендуется ссылаться на имя по стране/региону или по имени, существующем в службе имен доменов (Domain Name System, DNS). Также следует иметь в ввиду, что максимальный размер компонента домена (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=Diversión de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

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

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

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

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

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

Для протокола 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 и тире (-).

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

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

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

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

Дополнительные сведения о том, как Exchange выбирает сертификаты, см. в разделе Выбор TLS-сертификата SMTP.

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

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

Клонирование существующего сертификата

Приложение Exchange 2007 создает во время установки самозаверенный сертификат, который использует все имена серверов и доменов, известные приложению Exchange на момент установки. Эти сертификаты действительны в течение 12 месяцев. В некоторых случаях имеет смысл клонировать эти сертификаты, если имена субъектов и дополнительные имена субъектов могут использоваться для других компьютеров. Имейте в виду, что клонируются только метаданные сертификата, а не наборы ключей.

Чтобы выполнить следующий командлет на компьютере с установленной ролью пограничного транспортного сервера, необходимо войти в систему с учетной записью, входящей в локальную группу администраторов на этом компьютере.

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

Get-ExchangeCertificate -DomainName mail1.contoso.com

Где mail1.contoso.com — имя сервера или полное доменное имя, для которого требуется создать клонированный сертификат.

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

Чтобы клонировать сертификат, выполните следующую команду:

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

Где значение параметра Thumbprint берется из первого сертификата, приведенного в выходных данных для Get-ExchangeCertificate.

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

Создание запросов для сторонних служб сертификатов

Если для создания сертификатов используется центр сертификации, необходимо предоставить запрос сертификата в соответствии с требованиями центра сертификации.

Для создания запроса сертификата можно использовать командлет New-ExchangeCertificate. Используйте для создания запроса сертификата параметр GenerateRequest вместе с параметром Path, чтобы определить, где будет создан файл запроса. Итоговым файлом будет файл (с расширением REQ) запроса в формате PKCS #10. PKCS #10 — это стандарт синтаксиса запросов сертификатов, определяемый документом RFC 2314 (http://www.ietf.org/rfc/rfc2314.txt).

Примечание.
UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

В следующих примерах показаны некоторые типовые запросы сертификатов.

В первом примере создается запрос сертификата для сервера Contoso, mail1. Общее имя в имени субъекта содержит полное доменное имя сервера, и дополнительное имя субъекта содержит все принятые домены для Contoso.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

Во втором примере создается запрос сертификата для сервера Contoso, mail1. Сервер Contoso имеет соединители отправления на всех пограничных транспортных серверах с полным доменным именем mail.contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

В третьем примере создается запрос сертификата из существующего сертификата Contoso.com.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

В последнем примере показано, как создать запрос сертификата с помощью подстановочного знака для всех подчиненных доменов Contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

Дополнительные примеры см. в сообщении блога команды разработчиков Microsoft Exchange Опыт создания сертификата с помощью стороннего центра сертификации (на английском языке).

Примечание.
UNRESOLVED_TOKEN_VAL(exBlog)

Установка сертификатов, выданных по запросам сертификатов

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

Важно!
Не используйте оснастку «Диспетчер сертификатов», чтобы импортировать сертификаты для какой-либо службы на сервере Exchange. Использование оснастки «Диспетчер сертификатов» для импорта сертификатов на серверы Exchange завершается сбоем. Поэтому TLS и другие службы сертификатов Exchange не будут работать.

Не используйте оснастку «Диспетчер сертификатов», чтобы импортировать сертификаты для какой-либо службы на сервере Exchange. Использование оснастки «Диспетчер сертификатов» для импорта сертификатов на серверы Exchange завершается сбоем. Поэтому TLS и другие службы сертификатов Exchange не будут работать.

В следующем примере показано, как импортировать сертификат для службы TLS, работающей по протоколу SMTP.

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

В следующем примере показано, как импортировать сертификат и включить его для сервера клиентского доступа, который поддерживает клиентов POP3 (протокол Post Office Protocol, версия 3).

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

Дополнительные сведения

Дополнительные сведения о центрах сертификации, поддерживающих веб-узлы Exchange, см. в статье 929395 базы знаний Майкрософт Партнеры по предоставлению сертификатов для объединенных коммуникаций для сервера Exchange Server 2007 и Communications Server 2007 (эта ссылка может указывать на содержимое полностью или частично на английском языке).

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

Housley, Russ and Tim Polk (Хаусли, Русс и Тим Полк). Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure (Планирование инфраструктуры открытого ключа: руководство по развертыванию инфраструктуры открытого ключа). New York (Нью-Йорк): John Wiley & Son, Inc., 2001.
Adams, Carlisle and Steve Lloyd (Адамс, Карлайл и Стив Ллойд). Applied Cryptography: Protocols, Algorithms, and Source Code in C (Прикладная криптография: протоколы, алгоритмы и исходный код на Си), 2nd Edition (2-е издание). New York (Нью-Йорк): John Wiley & Son, Inc., 1996.
Рекомендации по реализации инфраструктуры открытого ключа Microsoft Windows Server 2003 (могут быть на английском языке)

Поделиться через