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

Шифрование и цифровые сертификаты очень важны в любой организации. По умолчанию Exchange Server настроен для шифрования обмена данными между внутренними серверами Exchange и между службами Exchange на локальном сервере с помощью ПРОТОКОЛА TLS. Но администраторы 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 создаются и устанавливаются два самозаверяющего сертификата. Microsoft Windows создает и устанавливает третий самозаверяющий сертификат для службы веб-управления в службах IIS. Эти сертификаты видны в Центре администрирования Exchange (EAC) и командной консоли Exchange и описаны в таблице ниже.

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

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

Ниже описано, что нужно учитывать при управлении сертификатами в 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 г. Exchange Server 2016 г. и Exchange Server 2019 г. поддерживает использование сертификатов шифрования на основе эллиптических кривых (ECC) для некоторых служб. Мы внесли некоторые важные изменения в обновление системы безопасности (SU) Exchange Server ноября 2024 г., чтобы устранить известные проблемы и включить поддержку сертификатов ECC для дополнительных сценариев (например, POP3 и IMAP). Перед включением поддержки сертификатов ECC обязательно установите последнее обновление Exchange Server.

Предупреждение

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

• Сертификат доверия федерации должен быть сертификатом RSA
• Сертификат Exchange Server OAuth должен быть сертификатом RSA.
• Сертификаты ECC не могут использоваться, если настроена проверка подлинности на основе утверждений AD FS

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

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

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

Переопределение, появившееся в Exchange Server обновлении исправлений (HU) за апрель 2024 г., больше не должно использоваться, так как оно не полностью включает поддержку сертификатов 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, которым могут быть назначены сертификаты, описаны в приведенной ниже таблице.

Служба	Описание	Поддерживается сертификат ECC
IIS (HTTP)	По умолчанию следующие службы предлагаются на веб-сайте по умолчанию в службах клиентского доступа на сервере почтовых ящиков и используются клиентами для подключения к Exchange: Автообнаружение Exchange ActiveSync Центр администрирования Exchange веб-службы Exchange Распространение автономных адресных книг Мобильный Outlook (протокол RPC через HTTP) MAPI Outlook через HTTP Outlook в Интернете Удаленная оболочка PowerShell* Так как с веб-сайтом можно связать только один сертификат, все DNS-имена, используемые клиентами для подключения к этим службам, необходимо указать в сертификате. Для этого можно использовать сертификат SAN или групповой сертификат.	Да
POP или IMAP	Сертификаты, используемые для POP или IMAP, могут отличаться от сертификата, используемого для IIS. Однако для упрощения администрирования рекомендуется также включить в сертификат IIS имена узлов, используемые для POP или IMAP, и использовать один сертификат для всех этих служб.	Да
SMTP	SMTP-подключения от клиентов или серверов обмена сообщениями принимаются одним или несколькими соединителями получения, настроенными в транспортной службе переднего плана на сервере Exchange Server. Подробнее см. в разделе Соединители получения. Чтобы требовать шифрование TLS для SMTP-подключений, можно использовать отдельный сертификат для каждого соединителя получения. Сертификат должен включать DNS-имя, которое используется клиентами SMTP или серверами для подключения к соединителю получения. Чтобы упростить управление сертификатами, рекомендуется включить все DNS-имена, для которых требуется поддержка трафика TLS, в один сертификат. Сведения о необходимости взаимной проверки подлинности TLS, при которой SMTP-подключения между исходным и целевым серверами шифруются и проходят проверку подлинности, см. в разделе Безопасность домена.	Да
EdgeSync	Дополнительные сведения см. в статье Подписки Edge в Exchange Server	Нет
Единая система обмена сообщениями	Дополнительные сведения см. в статье Deploying Certificates for UM. Примечание. UM недоступна в Exchange 2019.	Да
Гибридное развертывание с помощью Microsoft 365 или Office 365	Дополнительные сведения см. в статье Certificate Requirements for Hybrid Deployments.	Да
Secure/Multipurpose Internet Mail Extensions (S/MIME)	Дополнительные сведения см. в статье S/MIME для подписи и шифрования сообщений.	Нет

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

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

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

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

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

• Использование сертификатов из коммерческого ЦС для подключений клиентов и внешних серверов. Хотя вы можете настроить большинство клиентов, чтобы доверять любому сертификату или издателю сертификата, гораздо проще использовать сертификат из коммерческого ЦС для клиентских подключений к серверам Exchange. Для доверия сертификату, выданному коммерческим ЦС, на клиенте не требуется настройка. Многие коммерческие ЦС предлагают сертификаты, настроенные специально для Exchange. Вы можете использовать EAC или командную консоль 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, описаны в таблице ниже.

Property	Microsoft Exchange	Сертификат проверки подлинности Microsoft Exchange Server	WMSVC
Тема	CN=<ServerName> (например, CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (например, CN=WMSvc-Mailbox01)
Альтернативные имена субъектов (домены сертификатов)	<ServerName> (например, Mailbox01) <ServerFQDN> (например, Mailbox01.contoso.com)	none	WMSvc-<ServerName> (например, WMSvc-Mailbox01)
Имеет закрытый ключ (HasPrivateKey)	Да (True)	Да (True)	Да (True)
PrivateKeyExportable*	Неверно	Да	Да
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)
Службы IIS*	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, приведены в таблице ниже.

Property	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

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

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