Сертификаты могут быть использованы для шифрования трафика между двумя конечными точками (как клиентами, так и серверами). Также сертификаты могут применяться этими конечными точками для подтверждения своей подлинности друг другу. 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 полагаются на сертификаты 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.
Рисунок 1: Рисунок 1: Самоподписанный сертификат, созданный по умолчанию во время установки серверных ролей Exchange 2007 HUB, CAS, UM
Серверная роль 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.
Рисунок 2: Установка IntraOrgConnectorProtocolLogging для подробного вывода
Задавая так называемый IntraOrgConnectorProtocolLoggingLevel для подробного вывода, логгирование протокола будет добавлено к логу протокола коннектора отправки. После отправки письма из ящика, расположенного в сайте B в ящик, расположенный на Mailbox сервере Exchange 2007 в сайте A, просмотр лога протокола отправки позволяет обнаружить, что сервер Exchange Hub Transport в сайте B (Ex2007SE) использует сертификат, предложенный сервером Exchange Hub Transport в целевом сайте Active Directory (Ex2007EE) для того, чтобы обеспечить безопасность транспортного уровня, как можно видеть на рисунке 3.
Рисунок 3: Лог протокола отправки между сайтами Active Directory
Взглянув на сертификат на сервере Hub Transport, доступный для TLS, видно, что используется самоподписанный сертификат (рисунок 4).
Рисунок 4: Самоподписанный сертификат
С того момента, как между вашим внутренним сервером Hub Transport и сервером (серверами) Edge Transport сконфигурирован EdgeSync, оба сервера будут использовать сертификат для шифрования соединения. Кроме того, оба сертификата будут использоваться как способ предоставления прямого доверия. Прямое доверие — это такой метод аутентификации, при котором сертификат может быть использован для аутентификации, когда предоставленный сертификат присутствует в Active Directory (для серверной роли Hub Transport) или ADAM/LDS (для серверной роли Edge Transport). При настройке EdgeSync запрошенные сертификаты публикуются в правильном местоположении.
Всякий раз, когда SMTP открывает соединение с серверной ролью Hub/Edge Transport, Exchange разрешит использование гибкого TLS, предлагае его сертификат.
Сертификаты могут также использоваться сервером Hub/Edge Transport для настройки безопасности домена с организациями-партнерами как для шифрования, так и для аутентификации.
Сертификаты используются серверной ролью Client Access, чтобы обеспечить шифрование трафика между сервером Client Access и его различными клиентами. По умолчанию SSL требуется для:
Рисунок 5: Требовать SSL
Единственная вирутальная директория для которой использование сертификата не требуется по умолчанию — это та, которая делает автономную адресную книгу (OAB) доступной для скачивания для клиентов Microsoft Office Outlook 2007 и позже.
Рисунок 6: Виртуальная директория OAB Virtual не требует SSL по умолчанию
Имеется возможность настроить аутентификацию на основе сертификатов, разрешив таким образом клиентам подтверждать свою подлинность перед сервером Client Access, используя их персональные сертификаты.
Сертификаты используются серверной ролью Unified Messaging для шифрования канала связи при отправке сообщений голосовой почты для серверной роли Hub Transport. Сертификаты могут также использоваться для шифрования SIP и/или RTP-трафика направленного на шлюз UM IP, и должны использоваться, если вы решили разворачивать в вашей организации Office Communications Server, поскольку он связывается с другими серверными ролями только посредством шифрования.
Когда вы разворачиваете серверные роли Exchange 2007, за исключением роли Mailbox Server, Exchange создаст самоподписанный сертификат, и позволит использовать этот сертификат при необходимости для служб IIS, SMTP, POP3, IMAP4 и UM.
Давайте посмотрим на некоторые из особенностей самоподписанного сертификата, сгенерированного по умолчанию.
Самоподписанные сертификаты действительны лишь в течение одного года
Самоподписанные сертификаты действительны в течение одного года, как можно увидеть на рисунке 7, и должны быть обновлены по истечении года.
Рисунок 7: Самоподписанные сертификаты действительны лишь в течение одного года
Для обновления самоподписанного сертификата вы можете использовать в Exchange Management Shell командлет New-ExchangeCertificate. Если вы сначала получаете существующие сертификаты, запуская команду Get-ExchangeCertificate, вы можете передать объект командлету New-ExchangeCertificate, который сгенерирует новый самоподписанный сертификат с теми же настройками и активирует его для тех же служб по умолчанию.
На рисунке 8 вы можете увидеть как обновляется существующий самоподписанный сертификат.
Рисунок 8: Обновление существующего самоподписанного сертификата
Сервер клиентского доступа (Exchange 2007 Client Access) допускает активацию только одного сертификата для использования с IIS, но вы можете иметь множество сертификатов, включенных для POP, IMAP, UM и SMTP. Когда доступно много сертификатов, Exchange выберет сертификат, основанный на различных критериях. Я вернусь к процессу выбора сертификата во второй части данной статьи.
Самоподписанные сертификаты по умолчанию имеют одно общее имя и два альтернативных имени
Самоподписанный сертификат, созданный при развертывании Exchange 2007, будет иметь в качестве общего имени имя хоста сервера Exchange, и два альтернативных имени, установленных в имя хоста и полное различимое доменное имя (FQDN).
Рисунок 9: Самоподписанный сертификат и его Subject и CertificateDomains
Возможно однако сгенерировать самоподписанный сертификат с другим полем Subject и Subject Alternative Names для того, чтобы удостовериться, что он может использоваться в вашей организации Exchange.
Используя командлет New-ExchangeCertificate в Exchange Management Shell, вы можете создавать, например, сертификат с общим именем webmail.proexchange.global и затем задать альтернативыне имена такие как имя хоста и полное различимое доменное имя, как показано на рисунке 10.
Не забывайте добавлять двоичный параметр PrivateKeyExportable и устанавливать его в True, если вы хотите иметь возможным экспортировать этот самоподписанный сертификат для позволения вашим пользователям доверять ему (полностью об этом рассказано в части 2 этой статьи).
Рисунок 10: Создание нового самоподписанного сертификата с заданными альтернативными именами
Во второй части данной статьи я вернусь к требуемым именам сертификата. В третьей части я объясню более детально использованные командлеты.
Самоподписанному сертификату доверяет только его издатель
Важно знать, что самоподписанному сертификату доверяет только сам издатель сертификата, что может нарушить функциональность Exchange в случае неправильной настройки. Давайте посмотрим, что вам необходимо рассмотреть, если вы решили использовать самоподписанный сертификат:
Рисунок 11: Недоверие самоподписанному сертификату
Рисунок 12: Недоверие самоподписанному сертификату
В первой из трех частей этой статьи о сертификатах и Exchange вы увидели, какие из компонент Exchange 2007 используют сертификаты и какие характеристики имеются у самоподписанных сертификатов. Во второй части статьи я покажу как вы можете установить доверие самоподписанному сертификату и охвачу требования сертификата, которые необходимо иметь в виду, когда вы получаете сертификаты. Наконец, в 3 части статьи я рассмотрю различные доступные командлеты Exchange Management Shell, позволяющие создавать, управлять и удалять сертификаты Exchange.
Источник http://www.msexchange.org
Tags: domain, Exchange, imap, nat