Как упоминалось выше, многие компоненты Exchange Server 2007 используют сертификаты. Обычно при для всех внутренних передачах данных Exchange, защищенных сертификатами, не требуется сертификат, выпущенный общедоступным центром сертификации.

Весь внутренний трафик SMTP и трафик единой системы обмена сообщениями защищен самозаверяющими сертификатами, которые устанавливаются программой установки Exchange Server 2007. Хотя эти сертификаты требуется обновлять ежегодно с помощью командлета New-ExchangeCertificate, для стандартных компонентов обмена сообщениями Exchange не требуется общедоступный центр сертификации.

Примечание.

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

В Exchange Server 2007 имеется набор командлетов, которые позволяют создавать и запрашивать сертификаты TLS, а также управлять этими сертификатами. Дополнительные сведения об этих командлетах см. в подразделе Командлеты сертификатов далее в этом разделе. По умолчанию эти сертификаты являются самозаверяющими. Как объяснялось выше, самозаверяющий сертификат – это сертификат, подписанный его собственным создателем. В Exchange Server 2007 самозаверяющие сертификаты создаются компьютером, на котором выполняется Microsoft Exchange. При этом используется базовый API сертификатов Windows. Поскольку сертификаты являются самозаверяющими, то результирующие сертификаты будут иметь меньший уровень надежности, чем сертификаты, созданные центром сертификации. По этой причине самозаверяющие сертификаты рекомендуется использовать только для внутренних операций, указанных ниже.

• Сеансы SMTP между транспортными серверами-концентраторами: сертификат применяется только для шифрования сеанса SMTP. Проверка подлинности выполняется по протоколу Kerberos.
  
  
• Сеансы SMTP между транспортными серверами-концентраторами и пограничным транспортным сервером: сертификат применяется для шифрования сеанса SMTP и проверки подлинности на основе прямого доверия.
  
  
• Синхронизация EdgeSync между пограничными транспортными серверами и Active Directory: сертификат используется для шифрования сеансов связи LDAP между экземпляром ADAM на пограничных транспортных серверах и внутренними серверами Active Directory после репликации службой Microsoft Exchange EdgeSync данных из Active Directory в экземпляр ADAM на пограничном транспортном сервере.
  
  
• Единая система обмена сообщениями: сертификат используется для шифрования трафика SIP и RTP между серверами единой системы обмена сообщениями и шлюзами IP единой системы обмена сообщениями, IP-PBX и компьютерами с Office Communications Server 2007. Сертификат также используется для шифрования трафика SMTP при отправке голосовых сообщений и факсов с серверов единой системы обмена сообщениями на транспортные серверы-концентраторы.
  
  
• Сервер клиентского доступа, к которому получают доступ только внутренние клиенты.
  
  

Для внутренних компонентов Exchange можно использовать самозаверяющие сертификаты, так как они не применяются для проверки подлинности. Проверка подлинности для большинства компонентов Exchange выполняется на основе Kerberos или NTLM. Для связи между пограничным транспортным сервером и транспортным сервером-концентратором используется проверка подлинности на основе прямого доверия. Она выполняется на основе сертификата и того, что открытый ключ пограничного транспортного сервера хранится в Active Directory, которая являктся надежным хранилищем. В других случаях самозаверяющие сертификаты предоставляют временный ключ для шифрования обмена данными между компонентами Exchange.

Тем не менее для внешнего доступа клиентов из Интернета в сеть, в которой находится Exchange, требуется традиционная проверка доверия сертификатов. Для проверки доверия рекомендуется использовать сертификат, выданный общедоступным центром сертификации. Более того, если требуется проверка подлинности с помощью сертификата, настоятельно не рекомендуется применять самозаверяющие сертификаты. Сертификат, полученный от общедоступного центра сертификации, рекомендуется использовать в описанных ниже случаях.

• Доступ POP3-клиентов и IMAP4-клиентов к Exchange
  
  
• Outlook Web Access
  
  
• Мобильный Outlook
  
  
• Exchange ActiveSync
  
  
• Автообнаружение
  
  
• Безопасность домена
  
  

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

Командлет New-ExchangeCertificate создает запрос на сертификат в соответствии со спецификациями стороннего общедоступного центра сертификации, который выпустит сертификат.

Дополнительные сведения см. в следующих разделах:

• New-ExchangeCertificate
  
  
• Создание сертификата или запроса сертификата для TLS
  
  
• Опыт применения с Exchange Server 2007: создание сертификата с помощью стороннего центра сертификации
  
  

  Примечание.
  Содержимое и URL-адрес вики-страниц и блогов могут быть изменены без уведомления.

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

Определение типа и количества сертификатов, выпущенных общедоступным центром сертификации, для среды

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

• Поддержка клиентами подстановочных имен сертификатов   Определите, какие клиенты будут поддерживаться. Как указано выше, в данном случае клиентами называются клиенты, которые получают доступ к Exchange из Интернета.
  
  
• Пространство имен организации   Как настроено пространство имен IIS, доступное из Интернета?
  
  
• Источник сертификата   Где будет получен сертификат? Поддерживает ли выбранный общедоступный центр сертификации подстановочные значки в полях субъекта или дополнительного имени субъекта? Если нет, поддерживаются ли дополнительные имена субъекта?
  
  

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

Поддержка клиентами подстановочных имен сертификатов

Подстановочные имена могут использоваться в расширениях субъекта и дополнительного имени субъекта сертификатов X.509. Дополнительные сведения о подстановочных именах см. в подразделе «CertificateDomains» ниже в разделе Атрибуты сертификатов и их использование Exchange Server 2007.

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

Если клиент поддерживает подстановочные имена в сертификатах, планирование системы сертификатов в организации существенно упрощается. Если все клиенты поддерживают подстановочные имена, а в организации используется одно доменное имя, не требуется заниматься планированием пространства имена для стратении развертывания сертификатов. Вместо этого можно создать один сертификат, поддерживающий пространство имен с подстановочнм знаком. Например, если клиенты с Outlook Web Access испрользуют для доступа к почте mail.contoso.com/owa, а POP3-клиенты - pop.contoso.com, для них можно использовать один сертификат с подстановочным субъектом *.contoso.com.

Следующие клиенты Майкрософт поддерживают подстановочные имена в сертификатах:

• Outlook
  
  

  Примечание.
  При развертывании групповых сертификатов на серверах Exchange с ролью сервера клиентского доступа для обеспечения успешного подключения клиентов Outlook 2007 требуется настройка параметров службы автообнаружения. Дополнительные сведения об этой проблеме и способах ее устранения см. в разделе Проблемы с подключениями в мобильном Outlook, связанные с групповым сертификатом.

• Internet Explorer (Outlook Web Access)
  
  
• пограничный транспортный сервер (безопасность домена)
  
  

Важно!
Клиенты с Windows Mobile 5.0 не поддерживают шифрованный канал связи с серверами, в сертификатах которых используются подстановочные имена.

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

1. Приобретите сертификат, который содержит несколько имен, таких как mail.contoso.com, pop.contoso.com и mobile.contoso.com в расширении дополнительного имени субъекта.
   
   
2. Приобретите сертификат для каждого объекта в пространстве имен, к которому будет подключаться клиент.
   
   

Планирование пространства имен организации

Для подключения всем клиентам требуется URL-адрес или полное доменное имя. Каждый путь, к которому подключаются клиенты, должен быть сопоставлен с действительным сертификатом, который содержит имя узла, NetBIOS-имя, полное доменное имя узла или общее имя узла, к которому выполняется подключение. Определение списка имен, которые должен содержать сертификат, называется планированием пространства имен.

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

Необходимо изучить принципы планирования пространства имен сертификатов, чтобы определить, какие имена узлов требуктся включать в расшиерение дополнительных имен субъектоа используемого сертификата для защиты входящих подключений к Exchange Server 2007.

Дополнительные сведения см. в разделе Сведения о планировании пространств имен для Exchange Server 2007.

Способы получения сертификата

Как указано выше, для внешнего клиентского доступа рекомендуется приобрести сертификат от общедоступного стороннего центра сертификации.

При оценке центров сертификации обратите внимание на перечисленные ниже критерии.

• Разрешает ли центр сертификации использовать подстановочные имена в сертификате? Если колиенты поддерживают подстановочные имена в сертификате, приобретите сертификат в центре сертификации, поддерживающем подстановочные имена. Это позволит наиболее просто развернуть защищенные клиенты.
  
  
• Поддерживает ли центр сертификации разширение дополнительных имен субъекта? Рекомендуется использовать сертификат, поддерживающий несколько дополнительных имен субъекта, если выполняются следующие условия:
  
  
  • необходимо поддерживать клиенты, которые не поддерживают подстановочные имена в сертификате;
    
    
  • клиенты должны подключаться к нескольким путям к узлу.
    
    
  Корпорация Майкрософт в партнерстве с общедоступными центрами сертификации предоставляет сертификат объединенных коммуникаций. Актуальный список центров сертификации, которые поддерживают сертификат объединенных коммуникаций, см. в статье 929395 базы знаний Майкрософт Партнеры в области сертификатов объединенных коммуникаций для Exchange Server 2007 и Communications Server 2007 (на английском языке).
  
  
• Предоставляет ли центр сертификации высокий уровень проверки истинности? Некоторые центры сертификации очень доступные по цене, ежегодная стоимость сертификата в других достигает нескольких сотен долларов. Так как от целостности сертификата зависит проверка подлинности входящего трафика в организации, при выборе общедоступного центра сертификации рекомендуется руководствоваться не только ценой. Тщательно оцените и сравните услуги, которые предлагаются каждым центром сертификации, и их репутацию.
  
  

К началу

Как указано выше, поля сертификатов являются атрибутами в подписанных данных самого сертификата X.509. В этом разделе рассматриваются поля сертификата, которые используются службами Microsoft Exchange и выводятся в выходных данных командлета Get-ExchangeCertificate.

Некоторые из этих полей также являются параметрами, которые можно задать при создании сертификата или запроса сертификата с помощью командлета New-ExchangeCertificate. Дополнительные сведения о командлете New-ExchangeCertificate см. в разделе New-ExchangeCertificate.

Все поля сертификата в этом разделе перечислены в соответствии с порядком их вывода в выходных данных командлета Get-ExchangeCertificate. Все имена полей сертификата Exchange в этом разделе соответствуют именам расширений сертификата X.509.

Issuer

Subject

В этом поле указывается субъект сертификата. Subject - это строка X.500, которая обычно представлет одно имя, используемое для доступа к службе, применяющей сертификат. Если при создании сертификата с помощью командлета New-ExchangeCertificate субъект не задан явно, поле Subject будет содержать первое значение, указанное для параметра DomainName при выполнении компндлета New-ExchangeCertificate. Могут использоваться следующие поля X.500:

• C = страна
  
  
• ST = область
  
  
• L = место
  
  
• O = организация
  
  
• OU = подразделение
  
  
• CN = общее имя
  
  

Некоторые из этих полей требуются при создании запросов сертификатов из сторонних центров сертификации. Дополнительные сведения о поле Subject см. в разделе Создание сертификата или запроса сертификата для TLS.

Если перед Exchange развернут Microsoft Internet Security and Acceleration (ISA) Server 2006 и между ними существует мост, дополнительные сведения об именах субъектов и поведении ISA Server см. в сообщении блога Сертификаты с несколькими записями дополнительных имен субъекта могут препятсвовать веб-публикации ISA Server (на английском языке).

Примечание.
Содержимое и URL-адрес вики-страниц и блогов могут быть изменены без уведомления.

Когда Exchange создает самозаверяющий сертификат без аргументов пользователя, сертификат содержит имя субъкта CN=имя_узла.

Соответствующее расширение сертификата X.509 также имеет имя Subject.

Поле Subject задается с помощью параметра SubjectName в командлете New-ExchangeCertificate.

CertificateDomains

Поле CertificateDomains определеяет все DNS-имена домена, связанные с сертификатом. DNS-имена домена могут задаваться в атрибуте общего имени (cn=) субъекта либо в расширении дополнительных имен субъекта сертификата. В выходных данных командлета Get-ExchangeCertificate содержится домен, заданный в поле Subject, а также все домены в дополнительном имени субъекта.

Значения поля CertificateDomains могут включать имя узла или полное доменное имя, которые используются для доступа к серверу. Чтобы сертификат можно было использовать, полное доменное имя, применяемое клиентом для подключения к серверу, должно быть указано в поле CertificateDomains.

Например, если клиент подключается к серверу по протоколу POP3, а в качестве имени сервера используется mail.fourthcofee.com, сертификат, связанный с параметрами POP3, может содержать значение mail.fourthcofee.com в поле CertificateDomains.

Кроме того, в некоторых сертификатах используются подстановочные имена, например *.fourthcofee.com. Такой домен является допустимым. Тем не менее необходимо учитывать, что некоторые устарешие клиенты и мобильные устройства не поддерживают подстановочные имена в сертификатах и поэтому могут не поддерживать такие домены.

Примечание.
Поле дополнительного имени субъекта не предоставляется Exchange напрямую. Его можно просмотреть только в диспетчере сертификатов в консоли управления (MMC) или в диспетчере IIS. Сертификаты, привязанные к веб-узлу, например сертификаты, используемые IIS для Outlook Web Access, Exchange ActiveSync или автообнаружения, также можно просмотреть в диспетчере IIS.

Дополнительные сведения о применении дополнительных имен субъекта и подстановочных имен в сертификатах см. в разделе Создание сертификата или запроса сертификата для TLS. Кроме того, в блоге группы разработчиков Exchange Team Blog в статье Опыт применения с Exchange Server 2007: создание сертификата с помощью стороннего центра сертификации содержатся практические совыеты по созданию запроса сертификата с несколькими дополнительными именами субъекта

Примечание.
Содержимое и URL-адрес вики-страниц и блогов могут быть изменены без уведомления.

Имя расширения X.509 — Subject Alternative Name, но как указано выше, выходные данные командлета Get-ExchangeCertificate также добавляет значение, содержащееся в расширении сертификата Subject, с список имен в поле CertificateDomains.

Поле CertificateDomains задается с помощью параметров DomainName и Subject командлета New-ExchangeCertificate.

NotBefore и NotAfter

CertificateRequest

Как указано выше, свойства сертификата — это атрибуты, которые являются метаданными сертификата или закрытого ключа. Некоторые свойства являются неотъемлемой частью сертификата или закрытого ключа, например отпречаток сертификата, но многие из них можно изменять без повторной подписи сертификата

Кроме свойства Thumbprint, никакие свойства сертификатов Exchange не соответствуют расширениям сертификатов X.509.

В этом разделе объясняются свойства сертификатов.

IsSelfSigned

RootCAType

Services

Status

HasPrivateKey

Thumbprint

Windows, Windows Mobile и различные сторонние операционные системы включают набор встроенных сторонних общедоступных корневых центров сертификации. Если вы доверяете сертификатам, выпущенным этими сторонними корневыми центрами сертификации, это означает, что можно проверить сертификаты, выпущенные этими центрами.

Доверие является автоматическим, если выполняются следующие условия:

• в организации используется установка Windows по умолчанию;
  
  
• клиенты и мобильные устройства, используемые в организации, также доверяют встроенным сторонним общедоступным корневым центрам сертификации.
  
  

В этом случае дополнительная настройка доверия не требуется.

Частные доверенные корневые центры сертификации

Частный надежный корневой центр сертификации является корневым CA, который был развернут в соответствии с частной или внутренней инфраструктурой открытого ключа. Например, если организация развернула внутреннюю инфраструктуру PKI со своим собственным корневым сертификатом, необходимо выполнить дополнительную настройку доверия.

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

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

Существует два способа настройки доверия: прямое корневое доверие и перекрестная сертификация.

Прямое корневое доверие

Если нужно подтвердить надежность сертификата, выпущенного частным корневым центром сертификации, можно вручную добавить этот корневой сертификат в доверенное корневое хранилище сертификатов на компьютере с Windows. В некоторых случаях также можно доьавить сертификат в такое хранилище на мобильных клиентах. Дополнительные сведения о том, как вручную добавить сертификаты в локальное хранилище сертификатов на компьютере с Windows, см. в файле справки для оснастки диспетчера сертификатов в консоли управления (MMC). Дополнительные сведения об установке сертификатов на устройствах с Windows Mobile см. в разделе Установка сертификатов на устройствах под управлением Windows Mobilee (на английском языке).

Важно!

Возможно, не удастся установить сертификаты на всех компьютерах и устройствах, которые применяются пользователями для доступа к Exchange. Например, некоторые пользователю могут получать доступ к Outlook Web Access с киоска или компьютера знакомого. В этом сценарии появится предупреждение, но доступ к почте не будет запрещен. Так как такое поведение буквально учит пользователей пропускать предупреждения о сертификатах, не рекомендуется использовать этот вариант. Рекомендуется применять сертификаты, выпущенные доверенным сторонним центром сертификации.

Перекрестная сертификация

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

Когда служба, например служба транспорта Microsoft Exchange (при использовании SMTP/TLS) или IIS (при использовании HTTPS) получает сертификат, она проверяет сам сертификат и его цепочку. Проверка сертификата — это процесс, в котором подтверждается множество атрибутов сертификата. Большая часть этих атрибутов может быть подтверждена на локальном компьютере приложением, которое запрашивает сертификат. Например, планируемое использование сертификата, дата окончания срока действия сертификата и другие подобные атрибуты подтверждаются вне контекста инфраструктура открытого ключа. Однако проверка того, что сертификат был отозван, может быть подтверждена центром сертификации, который выпустил этот сертификат. Поэтому многие центры сертификации создают список отзыва сертификата с открытым доступом для подтверждения статуса отзыва.

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

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

Все общедоступные центры сертификации имеют общедоступные списки отзыва сертификатов, к которым могут обращаться серверы организации. В некоторых случаях, списки отзыва сертификатов для частных внутренних PKI доступны только по протоколу LDAP. В большинстве случаев при использовании общедоступных центров сертификации списки отзыва сертификатов публикуются по протоколу HTTP. Убедитесь в том, что соответствующие исходящие порты и прокси-серверы сконфигурированы таким образом, чтобы серверы и клиенты могли связываться со списком отзыва сертификатов. Чтобы узнать, какой протокол принимает конкретная точка распространения списков отзыва сертификатов, откройте сертификат в консоли управления MMC и обратите внимание на поле Точки распространения списков отзыва (CRL).

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

Настройка параметров прокси-сервера для служб WinHTTP

Чтобы протестировать конфигурацию PKI и прокси-сервера для конкретного сервера Exchange, проверьте цепочку сертификатов для сертификата сервера с помощью программы Certutil.exe. Certutil.exe — это средство командной строки, которое устанавливается вместе со службами сертификатов в операционных системах Windows Server. Дополнительные сведения см. в разделе Тестирование инфраструктуры открытого ключа и конфигурации прокси-сервера.

К началу

В прежних версиях Exchange Server управление сертификатами выполнялось с помощью IIS и диспечтера сертификатов в консоли управления (MMC). В Exchange Server 2007 большинство задач управления сертификатами выполняется с помощью следующих командлетов ExchangeCertificate в командной консоли Exchange:

• New-ExchangeCertificate. Этот командлет создает самозаверяющие сертификаты и запросы сертификатов для центров сертификации.
  
  
• Import-ExchangeCertificate. Этот командлет импортирует экспортированные сертификаты и файлы сертификатов, созданные центрами сертификации.
  
  
• Export-ExchangeCertificate. Этот командлет экспортирует сертификаты для резервного копирования или использования на нескольких серверах.
  
  
• Enable-ExchangeCertificate. Этот командлет включает определенные службы для сертификата.
  
  
• Get-ExchangeCertificate. Данный командлет выводит атрибуты сертификата.
  
  
• Remove-ExchangeCertificate. Данный сертификат удаляет сертификаты из Exchange Server и локального хранилища сертификатов.
  
  

Дополнительные сведения о создании запросов сертификатов см. в разделе Создание сертификата или запроса сертификата для TLS.

В следующих разделах приведены краткие примеры того, как можно использовать командлеты ExchangeCertificate для выполнения распространенных задач с сертификатами. Дополнительные сведения и примеры см. в справке командлета Get-ExchangeCertificate в разделе Глобальные командлеты.

Создание самозаверяющих сертификатов

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

	Копировать код
New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Клонирование самозаверяющихся сертификатов

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

	Копировать код
Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

Местозаполнитель thumbprint — это отпечаток обновляемого сертификата. Можно также указать в команде службы для нового сертификата:

	Копировать код
Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

После этого можно включить сертификат с помощью следующей команды:

	Копировать код
Enable-ExchangeCertificate <thumbprint>

Создание запросов сертификатов и установка доверенных сертификатов

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

В этом разделе описано, как включить использование сертификатов для службы POP3. В этом примере клиенты подключаются к службе POP3 с помощью полного доменного имени popserver.fourthcoffee.com.

Запрос сертификатов

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

	Копировать код
New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

Если запрос сертификата создан правильно, в корне системного диска будеи создан файл запроса сертификата (CER или DER), а командная консоль Exchange выведет отпечаток для запроса.

Примечание.
Сертификаты, возвращаемые поставщиками, могут иметь различное расширение имени файла, такое как CER или DER. Эти расширения указывают на способ шифрования, который применялся для файла сертификата. По умолчанию запрос New-ExchangeCertificate создает файл в кодировке Base64 (CER). Для созданрия DER-файла используйте параметр BinaryEncoded.

В предыдущей командк для параметра PrivateKeyExportable задается значение $True, что позволяет экспортировать сертификат вместе с закрытым ключом для использования на нескольких серверах Exchange, к которым требуется получать доступ с помощью одного полного доменного имени. Например, может использоваться балансировка нагрузки серверов клиентского доступа для поддержки подключений POP3.

Примечание.
Параметр PrivateKeyExportable является необязательным. Его нужно использовать только при создании запросов сертификатов для доверенных центров сертификации. Присвоение параметру PrivateKeyExportable значения $True позволяет перемещать и архивировать сопоставленные ключи. Это не требуется делать для самозаверяющих сертификатов.

Предыдущая команда также задает параметр Subjectname в качестве имени X.500. Большинство сторонних центров сертификации требуют указания допустимого имени X.500 для имени субъекта сертификата. По меньшей мере, большинство центров сертификации требуют, чтобы организации, указанной в поле organizationName (o=), принадлежало имя домена, указанное в поле commonName (cn=) веб-сервера.

После выполнения запроса файл запроса можно передать поставщику сертификата для получения сертификата.

Примечание.

Командлет Get-ExchangeCertificate возвращает сертификаты (в том числе ожидающие запросы сертификатов). Для отличия сертификатов от запросов запросы сертификатов содержат атрибут CertificateRequest, который выводит выходные данные, хранящиеся в файле запроса сертификата. Эти выходные данные можно использовать, если случайно удалить файл запроса сертификата или создать запрос без параметра. Данные CertificateRequest имеют кодировку base64. Их можно скопировать в файл и отправить центру сертификации для запроса сертификата.

Импорт сертификата

После возврата сертификата от центра сертификации его необходимо испортировать на сервер Exchange. Чтобы правильно импортировать сертификат, для которого был создан запрос с помощью командлета New-ExchangeCertificate, выполните следующую команду:

	Копировать код
Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

Если сертфикат успешно импортирован, будет возвращен отпечаток сертификата, который можно использовать для поддержки определенных служб.

Важно!
Необходимо импортировать сертификат на тот же компьютер, с которого создавался запрос. Для импорта нельзя использовать диспетчер сертификатов в консоли управления (MMC).

Включение сертификата

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

	Копировать код
Enable-ExchangeCertificate <thumprint> -Services:"POP"

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

	Копировать код
Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

Проверка установки сертификатов

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

	Копировать код
Get- ExchangeCertificate <thumbprint> | fl *

Примечание.
Если используется Exchange Server 2007 с пакетом обновления 1 (SP1) или более поздней версии, не включайте в аргумент команды звездочку (*).

Выходные данные этой команды выглядят приблизительно так:

Копировать код

AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com} HasPrivateKey : True IsSelfSigned : False Issuer : CN=3rdPartyCAExample.com NotAfter : 8/7/2008 10:04:02 AM NotBefore : 8/7/2007 10:04:02 AM PublicKeySize : 2048 RootCAType : ThirdParty SerialNumber : 83FAE8B2398F2A9E44485CBA85D548DF Services : POP Status : Valid Subject : C=us,o=contoso corp, CN=fourthcoffee.com Thumbprint : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

Просмотрите выходные данные, чтобы проверить следующее:

• нужные имена домена указаны в поле CertificateDomains;
  
  
• для свойства HasPrivateKey установлено значение True;
  
  
• свойство RootCAType настроено правильно. Дополнительные сведения о свойстве RootCAType см. в разделе Свойства сертификатов выше;
  
  
• включены нужные службы для сертификата;
  
  
• для параметра Status установлено значение Valid.
  
  

Для сертификата можно включить поддержку служб, таких как POP, IMAP, IIS и SMTP. Службы не являются полями сертификата. Это свойства метаданных сертификата, поэтому при их изменении сертификат не становится недопустимым.

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

POP и IMAP

При добавлении POP и IMAP в качестве дополнительных служб к сертификату в атрибут x509CertificateName объекта POPSettings или IMAPSettings добавляется домен, указанный в субъекте сертификата.

Например, чтобы убедиться, что объект POPSettings обновлен, выполните следующую команду:

	Копировать код
Get-POPSettings | fl *

Примечание.
Если используется Exchange Server 2007 с пакетом обновления 1 (SP1) или более поздней версии, не включайте в аргумент команды звездочку (*).

IIS

SMTP

Служба единой системы обмена сообщениями Microsoft Exchange

STARTTLS — эта команда SMTP, которая вызывает безопасный сеанс TLS. STARTTLS сообщается Exchange только при наличии допустимого сертификата на компьютере с Exchange.

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

• Исходящий STARTTLS. Сертификат выбирается на основе значения полного доменного имени на соединителе отравки.
  
  
• Входящий STARTTLS. Сертификат выбирается на основе значения полного доменного имени на соединителе приема.
  
  

  Примечание.
  Для входящего и исходящего STARTTLS если не указано полное доменное имя соединителя, используется полное доменное имя Exchange.

После определения полного доменного имени Exchange выполняет поиск допустимых сертификатов в хранилище личных сертификатов на компьютере. Сертификат допустим для TLS, если он отвечает следующим требованиям:

• поле Enhanced Key Usage содержит либо идентификатор объекта проверки подлинности сервера, либо NULL
  
  
• в расширении сертификатов PKI указан ключ RSA (не менее 1024 бит);
  
  
• можно выполнить проверку цепочки сертификатов до доверенного корня, или сертификат является самозаверяющим;
  
  
• сертификат и цепочка сертификатов проходят проверку на отзыв;
  
  
• существует и доступен закрытый ключ;
  
  
• закрытый ключ не хранится на съемном устройстве;
  
  
• закрытый ключ не защищен паролем.
  
  

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

• значение в поле NotBefore — выбирается самый новый сертификат;
  
  
• сертификаты, выпущенные доверенным центром сертификации, и самозаверяющие сертификаты — выбирается сертификат, выпущенный доверенным центром сертификации.
  
  

В большинстве случаев Exchange выбирает сертификат, выпущенный доверенным центром сертификации, а не самозаверяющий сертификат, вне зависимости от их возраста. Если допустимый сертификат не найден, STARTTLS не объявляется.

X-AnonymousTLS используется для защиты связи между двумя транспортными серверами-концентраторами или медду транспортными-серверами концентраторами и пограничными транспортными серверами. В Exchange 2007 с пакетом обновления 1 (SP1) упрощен процесс выбора сертификатов: если сертификат не обнаружен, для сеанса создается времнный ключ шифрования.

Exchange выполняет поиск всех сертификатов внутреннего транспорта. Если такой допустимый сертификат не удается найти, Exchange ищет допустимый сертификат из центра сертификации.

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

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

Как и при выборе сертификата для SMTP STARTTLS, для POP3 и IMAP4 сервер должен выбрать полное доменное имя и найти сертификат по соответствующему значению поля CertificateDomains. Полное доменное имя выбирается по значению атрибута X509CertificateName в параметрых службы POP3 или IMAP4. Атрибут X509CertificateName можно просмотреть с помощью командлета Get-POPSettings или Get-IMAPSettings. Дополнительные сведения см. в разделах Get-POPSettings и Get-IMAPSettings.

Выбор для POP3 и IMAP4 в Exchange 2007 с пакетом обновления 1 (SP1) выполняется так же, как для SMTP STARTTLS.

Примечание.

В окончательной первоначальной версии (RTM) Exchange 2007 существует два значительных отличия. Сертификаты, выпущенные доверенным центром сертификации, не являются предпочтительными по сравнению с самозаверяющими сертификатами. Вместо этого Exchange 2007 выбирает новейший сертификат. Кроме того, в окончательной первоначальной версии (RTM) Exchange 2007 для POP3 и IMAP4 не поддерживаются шаблоны доменов. Это значит, что если для атрибута X509CertificateName установлено занчение mail.fourthcoffee.com для параметров for POP3 или IMAP4, Exchange 2007 не будет поддерживать сертификат с доменом *.fourthcoffee.com .

Если служба единой системы обмена сообщениями Microsoft Exchange запускается в безопасном режиме, ею запрашивается локальное хранилище личных в поисках действительного сертификата, чтобы использовать его с протоколом TLS для шифрования. При этом сначала ищутся допустимые сертификаты, выданные частной PKI или общедоступным центром сертификации. Если сертификат найти не удается, будет выполнен поиск самозаверяющего сертификата. Если никакие сертификаты не найдены, служба единой системы обмена сообщениями Microsoft Exchange создаст самозаверяющий сертификат, чтобы использовать его для запуска в безопасном режиме. Если сервер единой системы обмена сообщениями запускается в небезопасном режиме, сертификат не нужен.

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

• имя поставщика
  
  
• серийный номер
  
  
• отпечаток
  
  

Отпечаток являеся хэшем SHA1. Он позволяет уникальным образом определить используемый сертификат. После этого сертификат, используемый службой единой системы обмена сообщениями  Microsoft Exchange для запуска в безопасном режиме, можно экспортировать из локального хранилища данных и импортировать его в доверенное хранилище сертификатов шлюзов IP и IP PBX в сети.

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

Когда сервер единой системы обмена сообщениями выполняет поиск сертификата, необходимого для использования протоколом MTLS для установки безопасного канала, сервер обращается к доверенному корневому хранилищу сертификатов. Если там находится несколько действительных сертификатов от разных поставщиков, сервер единой системы обмена сообщениями выбирает действительный сертификат с наибольшим оставшимся до истечения срока действия временем. Если существует несколько сертификатов, сервер единой системы обмена сообщениями выбирает сертификаты на основе поставщика и даты истечения срока действия. Сервер единой системы обмена сообщениями выполняет поиск действительных сертификатов в следующем порядке.

1. сертификаты PKI или общедоступные сертификаты с максимальным сроком действия;
   
   
2. сертификаты PKI или коммерческие сертификаты с минимальным сроком действия;
   
   
3. самозаверяющие сертификаты с максимальным сроком действия;
   
   
4. самозаверяющие сертификаты с минимальным сроком действия.
   
   

К началу