Цифровые сертификаты и шифрование в Exchange Server

Шифрование и цифровые сертификаты очень важны в любой организации. По умолчанию Exchange Server для шифрования связи между внутренними Exchange серверами и между Exchange службами на локальном сервере. Но администраторы Exchange должны сами настроить шифрование связи с внутренними и внешними клиентами (компьютерами и мобильными устройствами) и внешними серверами обмена сообщениями.

Примечание

Exchange Server 2019 г. включает важные изменения для повышения безопасности клиентских и серверных подключений. Настройка по умолчанию для шифрования поддерживает только TLS 1.2 и не поддерживает более ранние алгоритмы (а именно, DES, 3DES, RC2, RC4 и MD5). В ней также настроены алгоритмы обмена ключами эллиптических кривых, обладающие приоритетом над алгоритмами неэллиптических кривых. В Exchange Server 2016 и более поздних версиях все параметры шифрования наследуются из настройки, указанной в операционной системе. Дополнительные сведения см. в руководстве по Exchange Server TLS.

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

Процедуры, необходимые для сертификатов в Exchange Server, см. в Exchange Server.

Обзор цифровых сертификатов

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

Цифровые сертификаты используются в следующих целях:

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

  • Проверка подлинности. Они проверяют, что их владельцы (люди, веб-сайты и даже сетевые устройства, такие как маршрутизаторы) действительно являются тем, кто или как они себя утверждают. Обычно проверка подлинности является односторонней (исходный объект проверяет удостоверение целевого объекта), но также возможна взаимная проверка подлинности TLS.

Сертификаты могут выдаваться для различных целей, например проверки подлинности веб-пользователей и веб-серверов, S/MIME, IPsec и подписывания кода.

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

Ниже описаны три основных типа цифровых сертификатов.

Тип Описание Преимущества Недостатки
Самозаверяющий сертификат Сертификат подписывается приложением, которое его создает. Затраты (бесплатно). Клиентские компьютеры и мобильные устройства не доверяют такому сертификату по умолчанию. Его нужно вручную добавить в хранилище доверенных корневых сертификатов на всех клиентских компьютерах и устройствах, но внести изменения в хранилище доверенных корневых сертификатов можно не на всех мобильных устройствах.

Не все службы работают с самозаверяющими сертификатами.

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

Сертификат, выданный внутренним ЦС Сертификат, выданный инфраструктурой открытых ключей (PKI) в организации. Например, службы сертификации Active Directory (AD CS). Дополнительные сведения см. в статье Обзор служб сертификатов Active Directory. Позволяет организациям выдавать собственные сертификаты.

Дешевле сертификатов из коммерческого ЦС.

Сложность в развертывании и обслуживании PKI.

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

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

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

Метод Описание Преимущества Недостатки
Соответствие темы сертификата Поле Subject сертификата содержит общее имя (CN) узла. Например, сертификат, выданный сайту www.contoso.com, может использоваться для сайта https://www.contoso.com. Совместим со всеми клиентами, устройствами и службами.

Обособление. Отзыв сертификата для узла не влияет на другие узлы.

Количество необходимых сертификатов. Сертификат можно использовать только для указанного узла. Например, сертификат www.contoso.com нельзя использовать для ftp.contoso.com, даже если службы установлены на одном сервере.

Сложность. На веб-сервере для каждого сертификата требуется собственная привязка к IP-адресу.

Соответствие альтернативного имени субъекта (SAN) сертификата В дополнение к полю Subject, поле Subject Alternative Name сертификата содержит список нескольких имен узлов. Например:
  • www.contoso.com
  • ftp.contoso.com
  • ftp.eu.fabirkam.net
Удобство. Один сертификат можно использовать для нескольких узлов в отдельных доменах.

Большинство клиентов, устройств и служб поддерживают сертификаты SAN.

Аудит и безопасность. Вы точно знаете, какие узлы могут использовать сертификат SAN.

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

Отсутствие обособления. Нельзя выборочно отзывать сертификаты для указанных узлов, не влияя на все узлы в сертификате.

Соответствие группового сертификата Поле Subject сертификата содержит общее имя в виде подстановочного знака (*) и одного домена или поддомена. Например, *.contoso.com или *.eu.contoso.com. Групповой сертификат *.contoso.com можно использовать для:
  • www.contoso.com
  • ftp.contoso.com
  • mail.contoso.com
Гибкость. Вам не нужно предоставлять список хостов при запросе сертификата, и вы можете использовать сертификат на любое число хостов, которые могут понадобиться в будущем. Групповые сертификаты нельзя использовать с другими доменами верхнего уровня. Например, групповой сертификат *.contoso.com нельзя использовать для узлов *.contoso.net.

Групповые сертификаты можно использовать только для имен узлов на уровне подстановочного знака. Например, сертификат *.contoso.com нельзя использовать для сайта www.eu.contoso.com. Сертификат *.eu.contoso.com нельзя использовать для сайта www.uk.eu.contoso.com.

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

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

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

Сертификаты в Exchange

При установке Exchange 2016 или Exchange 2019 на сервере создается и устанавливается Exchange. Третий самозаверяемый сертификат создается и устанавливается корпорацией Майкрософт Windows для службы управления веб-службы IIS (IIS). Эти сертификаты видны в Центре администрирования Exchange (EAC) и командной консоли Exchange и описаны в таблице ниже.

Имя Комментарии
Microsoft Exchange Этому самозаверяющему сертификату Exchange присущи следующие возможности:
  • Сертификату автоматически доверяют все другие Exchange серверы организации. Это включает все серверы edge Transport, которые подписаны на Exchange организации.
  • Сертификат автоматически включается для всех служб Exchange, кроме единой системы обмена сообщениями, и используется для шифрования внутренней связи между серверами Exchange, службами Exchange на одном компьютере и клиентскими подключениями, которые передаются из служб клиентского доступа на серверы почтовых ящиков. (Примечание. В 2019 г. Exchange доступ к Exchange 2019 г.)
  • Сертификат автоматически активируется для входящих подключений с внешних серверов обмена сообщениями SMTP и исходящих подключений к внешним серверам обмена сообщениями SMTP. Эта конфигурация по умолчанию Exchange предоставлять оппортунистические TLS на всех входящие и исходящие соединения SMTP. Exchange пытается зашифровать сеанс SMTP на внешнем сервере обмена сообщениями, но если внешний сервер не поддерживает шифрование TLS, сеанс не шифруется.
  • Сертификат не обеспечивает шифрованную связь с внутренними или внешними клиентами. Клиенты и серверы не доверяют самозаверяющему сертификату Exchange, так как сертификат не определен в их хранилищах доверенных корневых сертификатов.
Сертификат проверки подлинности Microsoft Exchange Server Этот Exchange самозаверяемого сертификата используется для проверки подлинности и интеграции от сервера к серверу с помощью OAuth. Дополнительные сведения см. в Exchange Server plan SharePoint и Skype для бизнеса.
WMSVC Этот самозаверяющий сертификат Windows используется службой веб-управления IIS для удаленного управления веб-сервером и связанными с ним веб-сайтами и приложениями.

Если вы удалите этот сертификат и не выберете действительный сертификат, служба веб-управления не запустится. Наличие службы в этом состоянии может помешать установке Exchange обновлений или Exchange с сервера. Инструкции по исправлению этой проблемы см. в выпуске Event ID 1007 - служба веб-управления IIS проверки подлинности.

Свойства этих самозаверяющих сертификатов описаны в разделе Свойства самозаверяющих сертификатов по умолчанию.

Ниже описано, что нужно учитывать при управлении сертификатами в Exchange.

  • Для шифрования сетевого трафика между серверами Exchange и службами в вашей организации не нужно заменять самозаверяющий сертификат Microsoft Exchange.

  • Дополнительные сертификаты необходимы для шифрования подключений к серверам Exchange с помощью внутренних и внешних клиентов.

  • Дополнительные сертификаты необходимы для принудительного шифрования SMTP-подключений между серверами Exchange и внешними серверами обмена сообщениями.

Следующие элементы планирования и развертывания для Exchange Server являются важными драйверами для требований к сертификату:

Требования к сертификатам для служб Exchange Server

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

Служба Описание
IIS (HTTP) По умолчанию следующие службы предлагаются на веб-сайте по умолчанию в службах клиентского доступа на сервере почтовых ящиков и используются клиентами для подключения к Exchange:
  • Автообнаружение
  • Exchange ActiveSync
  • Центр администрирования Exchange
  • веб-службы Exchange
  • Распространение автономных адресных книг
  • Мобильный Outlook (протокол RPC через HTTP)
  • MAPI Outlook через HTTP
  • Outlook в Интернете
  • Remote PowerShell*

Так как с веб-сайтом можно связать только один сертификат, все DNS-имена, используемые клиентами для подключения к этим службам, необходимо указать в сертификате. Для этого можно использовать сертификат SAN или групповой сертификат.

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

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

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

Единая система обмена сообщениями Дополнительные сведения см. в статье Deploying Certificates for UM.

Примечание. В 2019 г. Exchange доступ к Exchange.

Гибридное развертывание с Microsoft 365 или Office 365 Дополнительные сведения см. в статье Certificate Requirements for Hybrid Deployments.
Secure/Multipurpose Internet Mail Extensions (S/MIME) Дополнительные сведения см. в статье S/MIME для подписи и шифрования сообщений.

*Проверка подлинности Kerberos и шифрование Kerberos используются для удаленного доступа к PowerShell как Exchange центра администрирования, так и Exchange management Shell. Поэтому не нужно настраивать сертификаты для использования с удаленной оболочкой PowerShell, если вы подключаетесь непосредственно к серверу Exchange (а не к пространству имен с балансировкой нагрузки). Чтобы с помощью удаленной powerShell подключиться к серверу Exchange с компьютера, который не является членом домена, или подключиться к интернету, необходимо настроить сертификаты для использования с помощью удаленной PowerShell.

Рекомендации по сертификатам Exchange

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

  • Используйте как можно меньше сертификатов. Скорее всего, это означает использование сертификатов SAN или сертификатов под диктовки. С точки зрения связи с Exchange оба функционально эквивалентны. Решение об использовании сертификата SAN и сертификата под диктовки больше о ключевых возможностях или ограничениях (реальные или воспринимаемые) для каждого типа сертификата, как описано в обзоре цифровых сертификатов.

    Например, если все общие имена будут находиться на одном уровне contoso.com, не имеет значения, какой сертификат использовать (SAN или групповой). Но для autodiscover.contoso.com, autodiscover.fabrikam.com и autodiscover.northamerica.contoso.com необходимо использовать сертификат SAN.

  • Используйте сертификаты из коммерческого ЦС для клиентских и внешних подключений к серверу . Хотя большинство клиентов могут доверять любому эмитенту сертификата или сертификата, гораздо проще использовать сертификат из коммерческого ЦС для клиентских подключений к Exchange серверам. Клиенту не требуется конфигурация, чтобы доверять сертификату, выданным коммерческим ЦС. Многие коммерческие ЦС предлагают сертификаты, настроенные специально для Exchange. Вы можете использовать EAC или Exchange для создания запросов сертификатов, которые работают с большинством коммерческих ЦС.

  • Выберите правильный коммерческий центр сертификации: сравните цены и функции сертификатов между CAs. Например:

    • Убедитесь, что центру сертификации доверяют клиенты (операционные системы, браузеры и мобильные устройства), которые подключаются к серверам Exchange.

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

    • Узнайте, предоставляет ли ЦС льготный период, в течение которого в сертификаты SAN можно бесплатно добавлять дополнительные общие имена.

    • Убедитесь, что лицензия позволяет использовать сертификат на нужном количестве серверов. Некоторые ЦС позволяют использовать сертификат только на одном сервере.

  • Используйте мастер Exchange сертификата. Распространенная ошибка при создании сертификатов — забыть одно или несколько распространенных имен, необходимых для служб, которые вы хотите использовать. Мастер сертификатов в центре администрирования Exchange поможет вам включить правильный список общих имен в запрос сертификата. Мастер позволяет указать службы, которые будут использовать сертификат, и включает общие имена, необходимые для этих служб. Запустите мастера сертификатов при развертывании исходного набора серверов Exchange или Exchange 2019 г. и определите, какие имена хостов будут использовать для различных служб для развертывания.

  • Используйте как можно меньше имен хостов. Минимизация числа имен хостов в сертификатах SAN снижает сложность управления сертификатами. Не чувствуйте себя обязанным включать имена отдельных серверов Exchange в сертификаты SAN, если это не требуется для использования сертификата. Как правило, для подключения к Exchange необходимо включить имена DNS, представленные внутренним клиентам, внешним клиентам или внешним серверам.

    Для простой Exchange Server организации с именем Contoso это гипотетический пример минимальных имен хостов, которые потребуются:

    • mail.contoso.com. Это имя хост охватывает большинство подключений к Exchange, включая Outlook, Outlook в Интернете, OAB-рассылку, Exchange веб-службы, Exchange центр администрирования и Exchange ActiveSync.

    • autodiscover.contoso.com. Это конкретное имя хоста требуется клиентами, которые поддерживают автонаружие, включая Outlook, Exchange ActiveSync и Exchange веб-службы. Дополнительные сведения см. в службе автооткрытия.

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

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

Свойство Microsoft Exchange Сертификат проверки подлинности Microsoft Exchange Server WMSVC
Тема CN=<ServerName> (например, CN=Mailbox01) CN=Microsoft Exchange Server Auth Certificate CN=WMSvc-<ServerName> (например, CN=WMSvc-Mailbox01)
Subject Alternative Names (CertificateDomains) <ServerName> (например, Почтовый ящик01)

<ServerFQDN> (например, Mailbox01.contoso.com)

Нет WMSvc-<ServerName> (например, WMSvc-Mailbox01)
Имеет закрытый ключ (HasPrivateKey) Да (True) Да (True) Да (True)
PrivateKeyExportable* False Да Да
EnhancedKeyUsageList* Проверка подлинности сервера (1.3.6.1.5.5.7.3.1) Проверка подлинности сервера (1.3.6.1.5.5.7.3.1) Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
IISServices* IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2 (например, IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2) none none
IsSelfSigned Да Да Да
Издатель CN=<ServerName> (например, CN=Mailbox01) CN=Microsoft Exchange Server Auth Certificate CN=WMSvc-<ServerName> (например, CN=WMSvc-Mailbox01)
NotBefore Дата и время установки Exchange. Дата и время установки Exchange. Даты и время установки службы веб-управления IIS.
Истекает срок действия (NotAfter) 5 лет спустя NotBefore. 5 лет спустя NotBefore. 10 лет спустя NotBefore.
Размер общедоступных ключей (PublicKeySize) 2048 2048 2048
RootCAType Реестр Нет Реестр
Службы IMAP, POP, IIS, SMTP SMTP Нет

*Эти свойства не видны в стандартном представлении в Exchange управленческой оболочки. Чтобы просмотреть их, необходимо указать имя свойства (точное или с использованием подстановочных знаков) с помощью командлетов Format-Table или Format-List. Например:

  • Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-List *

  • Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-Table -Auto FriendlyName,*PrivateKey*

Дополнительные сведения см. в рублях Get-ExchangeCertificate.

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

Свойство Microsoft Exchange Сертификат проверки подлинности Microsoft Exchange Server WMSVC
Алгоритм подписи sha256RSA1 sha256RSA1 sha256RSA1
Хэш-алгоритм подписи sha2561 sha2561 sha2561
Использование ключа Цифровая подпись, шифрование ключа (a0) Цифровая подпись, шифрование ключа (a0) Цифровая подпись, шифрование ключа (a0), шифрование данных (b0 00 00 00)
Основные ограничения Subject Type=End Entity

Path Length Constraint=None

Subject Type=End Entity

Path Length Constraint=None

н/д
Алгоритм отпечатка sha2561 sha2561 sha2561

1 Применяется к новым установкам Exchange 2016 Накопительного обновления 22 или более позднего и Exchange 2019 Накопительного обновления 11 или более поздней версии. Дополнительные сведения см. в Exchange Server сертификатов 2019 и 2016 годов, созданных во время установки, с использованием хаша SHA-1.

Как правило, диспетчер сертификатов Windows не используется для управления сертификатами Exchange (используется Центр администрирования Exchange или Командная консоль Exchange). Обратите внимание, что сертификат WMSVC не является сертификатом Exchange.