Управление сертификатами Exchange

Сертификаты могут быть использованы для шифрования трафика между двумя конечными точками (как клиентами, так и серверами). Также сертификаты могут применяться этими конечными точками для подтверждения своей подлинности друг другу. Exchange 2007 использует сертификаты X.509 для аутентификации и шифрования. Сертификаты X.509 соответствуют стандартному формату, опубликованному Telecommunication Standardization Sector (ITU-T).

Сертификат X.509 выпускается Certificate Authority (CA), который привязывает открытый ключ с желаемым Различимым именем, отформатированным согласно традиции X.500, или к так называемому Альтернативному имени или любому из Альтернативных имен субъекта.

В Exchange 2007 имеется несколько компонентов, которые полагаются на сертификаты при шифровании и/или аутентификации. В этой статье я представлю вам обзор обзор различных компонент Exchange, которые используют сертификаты. Далее я углублюсь в характеристики самоподписанных сертификатов, генерируемых по умолчанию. Во 2 части данной статьи я рассмотрю требования к именованию сертификата, о которых необходимо помнить при получении вами сертификатов. Наконец, в 3 части статьи я рассмотрю различные доступные командлеты Exchange Management Shell, позволяющие создавать, управлять и удалять сертификаты Exchange.

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

Как уже сказано, некоторые компоненты Exchange Server 2007 полагаются на сертификаты X.509 при шифровании и/или аутентификации. Вы заметите, что когда вы устанавливаете в Exchange 2007 серверные роли Hub Transport, Client Access, Unified Messaging и Edge Transport, Exchange по умолчанию создает самоподписанный сертификат для того, чтобы удостовериться, что этот сертификат работает как требуется при его использовании требуемыми компонентами.

Рисунок 1 ниже показывает вам самоподписанный сертификат, созданный Exchange во время установки серверных ролей Client Access, Hub и Unified Messaging в Exchange 2007. Этот сертификат будет использоваться следующими службами: IIS, SMTP, POP, IMAP и UM.

Серверные роли Hub/Edge Transport и сертификаты

Transport Layer Security между сайтами Active Directory

Серверная роль Exchange 2007 Hub Transport использует сертификат для шифрования всего SMTP-трафика между сайтами Active Directory. Невозможно сконфигурировать Exchange для пересылки нешифрованного SMTP-трафика между серверами Hub Transport, расположенными в различных сайтах.

Для того, чтобы увидеть, какой сертификат используется между двумя серверами Hub Transport, расположенными в различных сайтах Active Directory, вы можете включить логгирование протокола SMTP на внутреорганизационном коннекторе отправки (Send) на каждом сервере Hub Transport, как показано ниже на рисунке 2, используя командлет Set-TransportServer в Exchange Management Shell.

Задавая так называемый IntraOrgConnectorProtocolLoggingLevel для подробного вывода, логгирование протокола будет добавлено к логу протокола коннектора отправки. После отправки письма из ящика, расположенного в сайте B в ящик, расположенный на Mailbox сервере Exchange 2007 в сайте A, просмотр лога протокола отправки позволяет обнаружить, что сервер Exchange Hub Transport в сайте B (Ex2007SE) использует сертификат, предложенный сервером Exchange Hub Transport в целевом сайте Active Directory (Ex2007EE) для того, чтобы обеспечить безопасность транспортного уровня, как можно видеть на рисунке 3.

Взглянув на сертификат на сервере Hub Transport, доступный для TLS, видно, что используется самоподписанный сертификат (рисунок 4).

EdgeSync

С того момента, как между вашим внутренним сервером Hub Transport и сервером (серверами) Edge Transport сконфигурирован EdgeSync, оба сервера будут использовать сертификат для шифрования соединения. Кроме того, оба сертификата будут использоваться как способ предоставления прямого доверия. Прямое доверие - это такой метод аутентификации, при котором сертификат может быть использован для аутентификации, когда предоставленный сертификат присутствует в Active Directory (для серверной роли Hub Transport) или ADAM/LDS (для серверной роли Edge Transport). При настройке EdgeSync запрошенные сертификаты публикуются в правильном местоположении.

Гибкий Transport Layer Security

Всякий раз, когда SMTP открывает соединение с серверной ролью Hub/Edge Transport, Exchange разрешит использование гибкого TLS, предлагае его сертификат.

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

Сертификаты могут также использоваться сервером Hub/Edge Transport для настройки безопасности домена с организациями-партнерами как для шифрования, так и для аутентификации.

Серверная роль Client Access и сертификаты

Client Access

Сертификаты используются серверной ролью Client Access, чтобы обеспечить шифрование трафика между сервером Client Access и его различными клиентами. По умолчанию SSL требуется для:

• Outlook Web Access
• Outlook Anywhere
• Exchange ActiveSync
• POP3
• IMAP4
• Веб-сервисы Exchange: Автообнаружение, EWS, and Unified Messaging

Единственная вирутальная директория для которой использование сертификата не требуется по умолчанию - это та, которая делает автономную адресную книгу (OAB) доступной для скачивания для клиентов Microsoft Office Outlook 2007 и позже.

Аутентификация на основе сертификатов

Имеется возможность настроить аутентификацию на основе сертификатов, разрешив таким образом клиентам подтверждать свою подлинность перед сервером Client Access, используя их персональные сертификаты. Для получения дополнительной информации, обратитесь, пожалуйста, к данному блогу, созданому командой разработчиков по адресу msexchangeteam.org.

Серверная роль Unified Messaging и сертификаты

Сертификаты используются серверной ролью Unified Messaging для шифрования канала связи при отправке сообщений голосовой почты для серверной роли Hub Transport. Сертификаты могут также использоваться для шифрования SIP и/или RTP-трафика направленного на шлюз UM IP, и должны использоваться, если вы решили разворачивать в вашей организации Office Communications Server, поскольку он связывается с другими серверными ролями только посредством шифрования.

Как это соотносится с самоподписанным сертификатом?

Когда вы разворачиваете серверные роли Exchange 2007, за исключением роли Mailbox Server, Exchange создаст самоподписанный сертификат, и позволит использовать этот сертификат при необходимости для служб IIS, SMTP, POP3, IMAP4 и UM.

Характеристики этого самоподписанного сертификата Exchange

Давайте посмотрим на некоторые из особенностей самоподписанного сертификата, сгенерированного по умолчанию.

Самоподписанные сертификаты действительны лишь в течение одного года

Самоподписанные сертификаты действительны в течение одного года, как можно увидеть на рисунке 7, и должны быть обновлены по истечении года.

Для обновления самоподписанного сертификата вы можете использовать в Exchange Management Shell командлет New-ExchangeCertificate. Если вы сначала получаете существующие сертификаты, запуская команду Get-ExchangeCertificate, вы можете передать объект командлету New-ExchangeCertificate, который сгенерирует новый самоподписанный сертификат с теми же настройками и активирует его для тех же служб по умолчанию.

На рисунке 8 вы можете увидеть как обновляется существующий самоподписанный сертификат.

Сервер клиентского доступа (Exchange 2007 Client Access) допускает активацию только одного сертификата для использования с IIS, но вы можете иметь множество сертификатов, включенных для POP, IMAP, UM и SMTP. Когда доступно много сертификатов, Exchange выберет сертификат, основанный на различных критериях. Я вернусь к процессу выбора сертификата во второй части данной статьи.

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

Самоподписанный сертификат, созданный при развертывании Exchange 2007, будет иметь в качестве общего имени имя хоста сервера Exchange, и два альтернативных имени, установленных в имя хоста и полное различимое доменное имя (FQDN).

Возможно однако сгенерировать самоподписанный сертификат с другим полем Subject и Subject Alternative Names для того, чтобы удостовериться, что он может использоваться в вашей организации Exchange.

Используя командлет New-ExchangeCertificate в Exchange Management Shell, вы можете создавать, например, сертификат с общим именем webmail.proexchange.global и затем задать альтернативыне имена такие как имя хоста и полное различимое доменное имя, как показано на рисунке 10.

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

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

Самоподписанному сертификату доверяет только его издатель

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

• Outlook Anywhere и Exchange ActiveSync не поддерживают использование самоподписанного сертификата
• Веб-служба автообнаружения не будет проверять, является ли издатель сертификата доверенным, при запуске Microsoft Office Outlook 2007 с клиентского ПК, присоединенного к домену, но будет выражать недовольство сертификатом, если вы используете Microsoft Office Outlook 2007 с клиентского ПК, не входящего в домен, как показано на рисунке 11.

• Когда клиенты Microsoft Office Outlook 2007 (входящие в домен или нет) используют службы Exchange Web, предоставляемые сервером Microsoft Exchange Client Access, Outlook известит их, что сертификат выпущен не той компанией, которую они выбрали в качестве доверенной. Рисунок 12 показывает Предупреждение безопасности в случае, когда кто-то запрашивает информацию Free and Busy.

• Microsoft поддерживает использование самоподписанных сертификатов, но лишь для внутренних сценариев, например: - для шифрования SMTP сессий между серверами Hub Transport в различных сайтах; - для шифрования SMTP сессий между серверами Hub Transport и серверами Edge Transport servers; - для шифрования синхронизации конфигураций и информации о получателях с помощью настройки EdgeSync между внутренними серверами Hub Transport и сервером (серверами) Edge Transport; - для шифрования SMTP сессий между серверами Unified Messaging и серверами Hub Transport; - для шифрования SIP и RTP сессий между серверами Unified Messaging и серверами Office Communications (это потребует удостовериться, что сервер Office Communication Mediation доверяет вашему серверу Exchange как издателю данного самоподписанного сертификата; - для шифрования доступа внутренних клиентов к Exchange (POP,IMAP,Outlook Web Access).
• Если вы не хотите, чтобы Exchange генерировал самоподписанный сертификат во время установки, вы можете задать в командной строке следом за Setup параметр /NoSelfSignedCertificates. Будьте осторожны: этот параметр может быть использован лишь при установке серверной роли Client Access или серверной роли Unified Messaging. Если у вашего сервера нет доступного действующего сертификата для шифрования соединения между клиентами и сервером Client Access или сервером Unified Messaging, соединение будет нешифрованным, таким образом, небезопасным.

Заключение

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