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

ПРИМЕНЯЕТСЯ К:2016 2019 по подписке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Балансировка нагрузки: планируете ли вы завершить работу зашифрованного канала в балансировщике нагрузки или обратном прокси-сервере, использовать балансировщики нагрузки уровня 4 или 7, а также использовать сходство сеансов или без них? Дополнительные сведения см. в статье Балансировка нагрузки в Exchange 2016.

• Планирование пространства имен: какие версии Exchange существуют, используется ли модель связанного или несвязанного пространства имен и используется ли разделенная DNS (настройка разных IP-адресов для одного узла на основе внутреннего и внешнего доступа)? Дополнительные сведения см. в статье Планирование пространства имен в Exchange 2016.

• Подключение клиентов: какие службы будут использоваться клиентами (веб-службы, протокол POP, IMAP и т. д.) и какие версии Exchange будут задействованы? Дополнительную информацию см. в следующих статьях:

  • Подключения клиентов в смешанной среде Exchange 2016 и Exchange 2013

  • Подключения клиентов в смешанной среде Exchange 2016 и Exchange 2010

  • Подключения клиентов в смешанной среде Exchange 2016 и другие версии Exchange

Поддержка сертификатов шифрования эллиптических кривых в Exchange Server

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

Начиная с обновления исправлений Exchange Server за апрель 2024 г. (HU) Exchange Server 2016 и Exchange Server 2019 поддерживают использование сертификатов шифрования на основе эллиптических кривых (ECC) для некоторых служб. В обновлении безопасности (SU) за ноябрь 2024 г. для Exchange Server внесены некоторые важные изменения, чтобы устранить известные проблемы и включить поддержку сертификата ECC для дополнительных сценариев (например, POP3 и IMAP). Перед включением поддержки сертификата ECC обязательно установите последнее обновление Exchange Server.

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

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

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String

Переопределение, которое появилось в обновлении исправлений (HU) за апрель 2024 г. для Exchange Server, больше нельзя использовать, так как оно не полностью включает поддержку сертификата ECC. Рекомендуется удалить переопределение. Откройте новую командную консоль Exchange (EMS) после New-SettingOverride выполнения команды:

Get-SettingOverride | Where-Object {($_.SectionName -eq "ECCCertificateSupport") -and ($_.Parameters -eq "Enabled=true")} | Remove-SettingOverride
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

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

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

^* Проверка подлинности Kerberos и шифрование Kerberos используются для удаленного доступа PowerShell из Центра администрирования Exchange и командной консоли Exchange. Поэтому не нужно настраивать сертификаты для использования с удаленной оболочкой 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. Для создания запросов на сертификат, которые работают с большинством коммерческих центров сертификации, можно использовать Центр администрирования Exchange или командную консоль Exchange.

• Выберите подходящий коммерческий центр сертификации: сравните цены на сертификаты и функции центров сертификации. Например, вы можете:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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