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

Использование сертификатов в Exchange Server 2007

  • Статья

 

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

Последнее изменение раздела: 2008-05-19

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

  • способ применения сертификатов в Exchange Server 2007;

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

  • использование атрибутов сертификата компонентами Exchange Server 2007 и соотношение свойств сертификата с полями расширения сертификата X.509;

  • доверие и проверка сертификатов;

  • создание, импорт и включение сертификатов Exchange Server 2007;

  • выбор сертификатов компонентами Exchange из личного хранилища компьютера.

Каждый раздел содержит ссылки на документацию для Exchange Server 2007, связанную с сертификатами.

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

Содержание

  • Компоненты Exchange Server 2007, применяющие сертификаты для шифрования или проверки подлинности сеансов

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

  • Атрибуты сертификатов и их использование Exchange Server 2007

  • Доверие и проверка сертификатов

  • Создание, импорт и включение сертификатов

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

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

Компоненты Exchange Server 2007, применяющие сертификаты для шифрования или проверки подлинности сеансов

Exchange Server 2007 использует сертификаты X.509 для согласования транспортных каналов связи для протоколов, таких как HTTPS, SMTP, POP и IMAP.

TLS — это стандартный протокол IETF, обеспечивающий конфиденциальность и безопасность взаимодействия двух приложений через сеть. Он обеспечивает шифрование передаваемых данных и позволяет клиентам выполнять проверку подлинности серверов и наоборот. Протокол TLS является более защищенной версией предшествующего ему протокола SSL, который был разработан компанией Netscape. Функции обоих протоколов совпадают. Большинство реализаций поддерживают оба протокола для обеспечения обратной совместимости с клиентами прежних версий, поддерживающих только SSL.

Защиту на основе протокола TLS можно использовать только для обеспечения конфиденциальности (шифрования) либо для обеспечения конфиденциальности и проверки подлинности. Сертификаты X.509 могут быть самозаверяющими или выпущенными центром сертификации X.509. Центр сертификации X.509 — это либо сторонний общедоступный центр сертификации, либо инфраструктура открытого ключа (PKI), развернутая в организации. Если не указано иное, этот раздел относится к обоим видам центров сертификации. Сторонние общедоступные центры сертификации будут называться сторонними общедоступными центрами сертификации.

Ниже описаны компоненты Exchange Server 2007, применяющие сертификаты для шифрования или проверки подлинности сеансов.

  • SMTP. Сертификаты используются для шифрования и проверки подлинности для обеспечения безопасности домена между партнерскими организациями. Сертификаты применяются для подключений на основе прямого доверия между транспортными серверами-концентраторами и пограничными транспортными серверами. Сертификаты используются между транспортными серверами-концентраторами для шифрования сеансов SMTP. В Exchange Server 2007 прямое доверие — это функция проверки подлинности, при которой наличие сертификата службы каталогов Active Directory или ADAM свидетельствует о проверке сертификата. Active Directory считается доверенным механизмом хранения. Сертификаты также используются для сеансов гибкого TLS между организациями. Дополнительные сведения см. в разделе Функции TLS и связанные термины в Exchange Server 2007.

  • Синхронизация EdgeSync. Самозаверяющий сертификат, созданный Exchange Server 2007, используется для шифрования сеансов связи LDAP между экземпляром ADAM на пограничных транспортных серверах и внутренними серверами Active Directory после репликации службой Microsoft Exchange EdgeSync данных из Active Directory в экземпляр ADAM на пограничном транспортном сервере. Самозаверяющий сертификат – это сертификат, подписанный его собственным создателем. Microsoft Exchange EdgeSync — это служба синхронизации данных, которая выполняет периодическую репликацию данных конфигурации из Active Directory на подписанный пограничный транспортный сервер. Дополнительные сведения см. в разделе Общие сведения о процессе синхронизации EdgeSync.

  • POP3 и IMAP4. Сертификаты применяются для проверки подлинности и шифрования сеансов между POP3-и IMAP4-клиентами и серверами Exchange. Дополнительные сведения см. в разделе Управление безопасностью POP3 и IMAP4.

  • Единая система обмена сообщениями. Сертификаты применяются для шифрования сеансов SMTP для транспортных серверов-концентраторов, шлюза IP единой системы обмена сообщениями и Microsoft Office Communications Server 2007. Дополнительные сведения см. в разделе Общие сведения о безопасности VoIP единой системы обмена сообщениями.

  • Автообнаружение. Сертификаты применяются для шифрования пути HTTP между клиентами и сервером клиентского доступа. Дополнительные сведения см. в разделе Технический документ: служба автообнаружения Exchange Server 2007 (на английском языке).

  • Приложения клиентского доступа. Сертификаты используется для шифрования пути между серверами клиентского доступа и различными HTTP-клиентами, такими как мобильный Outlook, Microsoft Outlook Web Access и устройства, поддерживающие Microsoft Exchange ActiveSync. Дополнительные сведения см. в разделе Управление безопасностью клиентского доступа.

Дополнительные сведения о шифровании и проверке подлинности для определенных видов связи в Exchange Server 2007 см. в разделе Справка по безопасности путей данных.

В начало

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

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

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

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

Рекомендуется развернуть сертификат, выпущенный общедоступным центром сертификации, если пользователи получают доступ к компонентам Exchange, требующим проверки подлинности и шифрования, из-за пределов корпоративного брандмауэра. Например, все различные клиенты, поддерживаемые ролью сервера клиентского доступа, такие как Exchange ActiveSync, POP3, IMAP4 и мобильный Outlook, должны защищаться сертификатом, выпущенным общедоступным центром сертификации. В данном разделе такие компоненты называются внешними компонентами Exchange Server 2007. Термин внешний указывает на тот факт, что данные, передаваемые между клиентами и серверами Exchange Server 2007, пересекают корпоративный брандмауэр и выходят в Интернет.

Внутренние компоненты, использующие самозаверяющие сертификаты

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

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

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

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

  • Доступ POP3-клиентов и IMAP4-клиентов к Exchange

  • Outlook Web Access

  • Мобильный Outlook

  • Exchange ActiveSync

  • Автообнаружение

  • Безопасность домена

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

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

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

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

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

  • Internet Explorer (Outlook Web Access)

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

importantВажно!
Клиенты с 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 (на английском языке).

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

В начало

Атрибуты сертификатов и их использование Exchange Server 2007

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

Сертификаты X.509 имеют два типа атрибутов.

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

  • Свойства сертификата - это атрибуты, которые являются метаданными сертификата или закрытого ключа. Некоторые свойства являются неотъемлемой частью сертификата или закрытого ключа, например отпречаток сертификата. Тем не менее многие свойства можно изменять без повторной подписи сертификата.

    Например, командлет Enable-ExchangeCertificateпозволяет добавлять службы в свойства созданных сертификатов. Можно включить использование сертификатов службами IIS (Outlook Web Access или Exchange ActiveSync), SMTP (прямое доверие или безопасность домена), IMAP, POP и единой системой обмена сообщениями. При включении для сертификата поддержки определенной службы его свойства обновляются. Дополнительные сведения см. в разделе Enable-ExchangeCertificate.

Чтобы просмотреть атрибуты, выполните командлет Get-ExchangeCertificate с аргументом |FL для нужного сертификата. В окончательной первоначальной версии (RTM) Exchange Server 2007 для вывода всех данных атрибутов необходимо выполнить этот командлет с аргументом |FL* .

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

Поля сертификата

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

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

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

Issuer

Это поле содержит общее имя издателя сертификата. Для самозаверяющих сертификатов, которые создаются Exchange при установке или с помощью командлета New-ExchangeCertificate, выводится cn=имя_узла, где имя_узла - это имя локального сервера.

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

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

Поле Issuer не имеет соответствующего параметра, который можно задать с помощью командлета New-ExchangeCertificate. Поле 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 (на английском языке).

noteПримечание.
Содержимое и 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. Такой домен является допустимым. Тем не менее необходимо учитывать, что некоторые устарешие клиенты и мобильные устройства не поддерживают подстановочные имена в сертификатах и поэтому могут не поддерживать такие домены.

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

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

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

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

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

NotBefore и NotAfter

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

Имя расширения сертификатов X.509, соответствующее значению NotBefore, — Valid from. Имя расширения сертификатов X.509, соответствующее значению NotAfter, — Valid to.

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

CertificateRequest

Это значение присутствует только для запрошенных сертификатов. Запросы сертификатов не являются допустимыми сертификатами X.509 и поэтому не используются Exchange.

Чтобы включить поле CertificateRequest, необходимо использовать параметр GenerateRequest командлета New-ExchangeCertificate.

Свойства сертификатов

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

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

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

IsSelfSigned

Свойство IsSelfSigned указывает, является ли сертификат самозаверящим. Самозаверяющий сертификат обычно является корневым. У этого сертификата нет других сертификатов в цепочке. Самозаверяющими сертификатами в Exchange обычно являются следующие:

  • сертификат, который создается при установке Exchange на сервер, на котором нет допустимого сертификата;

  • сертификат, который создается с помощью командлета New-ExchangeCertificate.

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

RootCAType

Свойство RootCAType определяет тип центра сертификации, который выдал сертификат. Если для параметра IsSelfSignedустановлено значение True, то для параметра RootCATypeдолжно быть установлено значение None. В противном случае при выборе сертификата могут возникать непредвиденные результаты. Ниже описаны другие возможные значения.

  • Registry. Внутренний частный корневой центр сертификации PKI, вручную установленный в хранилище сертификатов.

  • ThirdParty. Общедоступный сторонний корневой центр сертификации.

  • GroupPolicy. Внутренний частный корневой центр сертификации PKI, развернутый с помощью групповой политики.

  • Enterprise. Внутренний частный корневой центр сертификации PKI, развернутый с помощью Active Directory.

  • Unknown. Exchange не удается определить тип установленного сертификата.

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

Например, значение Registry указывает, что сертификат вручную установлен на одном сервере. Если сертификат не установлен на других серверах в организации, это может привести к несоответствию. Рекомендуется распространять сертификаты на все компьютеры с помощью групповой политики или Active Directory.

Services

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

Поле Services задается с помощью параметра Services командлета Enable-ExchangeCertificate. Дополнительные сведения см. в разделе Enable-ExchangeCertificate.

Status

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

  • Unknown. Это состояние обычно указывает на то, что состояние сертификата не удалось проверить, так как недоступен список отзыва сертификатов или серверу не удается к нему подключиться. Убедитесь, что компьютер может подключиться к центру отзыва сертификатов. Дополнительные сведения см. в разделе Настройка параметров прокси-сервера для служб WinHTTP.

  • Valid. Сертификат работает правильно.

  • Revoked. В списке отзыва сертификатов указано, что этот сертификат отозван. Необходимо создать новый сертификат.

  • DateInvalid. Это состояние указывает на то, что системное время неправильное, срок действия сертификата истек, или в системе, подписавшей файл, установлено неправильное время. Проверьте, выполнены ли следующие условия:

    • часы на локальном компьютере показывают точное время;

    • срок действия сертификата не истек;

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

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

  • Untrusted. Это состояние указывает, что сертификат не является самозаверящим. Сертификат подписан центром сертификации, которому не доверяет локальный компьютер. Необходимо добавить сертификат в хранилище доверенных корневых центров сертификации на компьютере. Дополнительные сведения о том, как вручную добавить сертификаты в локальное хранилище сертификатов, см. в файле справки для оснастки диспетчера сертификатов в консоли управления (MMC).

  • Invalid. Сертификат является недопустимым по какой-либо другой причины (например, из-за наличия ненадежного, недопустимого или отозванного сертификата в пути сертификата).

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

HasPrivateKey

Свойство HasPrivateKey указывает, есть ли у установленного сертификата закрытый ключ. Это очень важно, так как служба транспорта Microsoft Exchange, служба Microsoft Exchange POP3 и служба Microsoft Exchange IMAP4 не используют сертификаты без закрытых ключей.

Thumbprint

Свойство Thumbprint — это уникальная строка, определяющая сертификат. Если один и тот же сертификат установлен на нескольких серверах Exchange, их можно определить по отпечатку. Один и тот же сертификат обычно устанавливается на несколько серверов Exchange, если несколько пограничных транспортных серверов принимают почту с одним полным доменным именем, например mail.fourthcoffee.com. Более экономно устанавливать один и тот же сертификат на нескольких серверах, чем запрашивать новые сертификаты для каждого сервера. Тем не менее сертификат должен иметь экспортируемый частный ключ.

Свойство Thumbprint позволяет указать сертификат для следующих командлетов:

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

В начало

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

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

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

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

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

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

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

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

  • в организации используется установка Windows по умолчанию;

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

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

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

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

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

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

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

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

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

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

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

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

Настройка доступа к списку отзыва сертификата

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

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

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

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

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

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

Для управления всем трафиком HTTP и HTTPS серверы Exchange Server 2007 используют службы Windows HTTP (WinHTTP). И транспортные серверы-концентраторы, и пограничные транспортные серверы могут использовать протокол HTTP для доступа к стандартным обновлениям фильтра нежелательной почты для Exchange Server 2007 и службе обновлений средства защиты от нежелательной почты Microsoft Forefront Security для Exchange Server. Все роли сервера Exchange используют WinHTTP для проверки по списку отзыва сертификатов.

Дополнительные сведения см. в разделе Настройка параметров прокси-сервера для служб WinHTTP.

Тестирование конфигурации инфраструктуры открытого ключа и прокси-сервера

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

В начало

Создание, импорт и включение сертификатов

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

В этом разделе описаны операции, которые можно выполнять с сертификатами в Exchange Server 2007. Прочтите этот раздел, если вы не знакомы с командлетами ExchangeCertificate. Ниже в документе приеведены примеры и процедуры для конкретных приложений (в данном случае — для POP3). Этот раздел также содержит ссылки на документацию для отдельных приложений.

Командлеты сертификатов

В прежних версиях 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 выведет отпечаток для запроса.

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

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

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

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

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

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

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

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

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

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

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

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

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

Enable-ExchangeCertificate <thumprint> -Services:"POP"

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

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

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

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

Get- ExchangeCertificate <thumbprint> | fl *
noteПримечание.
Если используется 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 *
noteПримечание.
Если используется Exchange Server 2007 с пакетом обновления 1 (SP1) или более поздней версии, не включайте в аргумент команды звездочку (*).

IIS

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

Чтобы включить для сертификата поддержку IIS, выполните командлет Enable-ExchangeCertificate только на веб-узле IIS по умолчанию. Если Outlook Web Access или служба автообнаружения находятся на другом веб-узле, потребется сопоставить сертификат с этим узлом с помощью диспечтера IIS.

SMTP

При включении для сертификата службы SMTP учетной записи сетевой службы предоствляется доступ на чтение к соответствующему файлу закрытого ключа в папке Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys. При этом предоставляется разрешение, необходимое транспортной службе Microsoft Exchange для доступа и использования закрытого ключа для расшифровки сообщений, защищенных TLS.

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

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

  • роль сервера единой системы обмена сообщениями установлена на этом компьютере;

  • сертификат содержит физическое полное доменное имя локального компьютера в поле CertificateDomains.

В начало

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

Выбор сертификата — это процесс, который компоненты Exchange выполняют для определения того, какой сертификат необходимо использовать для входяшего подключения SMTP STARTTLS, POP3 и IMAP4 выполняют аналогичный процесс подключния, чтобы определить, какой сертификат использовать в определенном сеансе. Такой процесс достаточно однозначен. Тем не менее он может приводить в замешательство, особенно если на компьютере установлено несколько сертификатов.

В этом разделе описан процесс выбора сертификтов для SMTP STARTTLS, SMTP X-AnonymousTLS, POP3 и IMAP4. Дополнительные сведения о выборе сертификатов для транспорта см. в разделе Выбор TLS-сертификата SMTP.

SMTP STARTTLS

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

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

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

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

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

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

  • поле Enhanced Key Usage содержит либо идентификатор объекта проверки подлинности сервера, либо NULL

  • в расширении сертификатов PKI указан ключ RSA (не менее 1024 бит);

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

  • сертификат и цепочка сертификатов проходят проверку на отзыв;

  • существует и доступен закрытый ключ;

  • закрытый ключ не хранится на съемном устройстве;

  • закрытый ключ не защищен паролем.

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

  • значение в поле NotBefore — выбирается самый новый сертификат;

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

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

SMTP X-AnonymousTLS

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

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

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

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

POP3 и IMAP4

Как и при выборе сертификата для 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.

noteПримечание.
В окончательной первоначальной версии (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. самозаверяющие сертификаты с минимальным сроком действия.

В начало

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

В данном разделе упомянуты следующие документы:

В начало