Exchange Server 中的数字证书和加密
加密和数字证书是所有组织的重要考虑因素。 默认情况下，Exchange Server 配置为使用传输层安全性 (TLS) 来加密内部 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 中的证书过程。
数字证书概述
数字证书是一种电子文件，其作用如同联机密码一样，可验证用户或计算机的身份。 数字证书用于创建客户端通信所用的加密通道。 证书是由证书颁发机构 (CA) 颁发的数字声明，用于证明证书持有者的身份，并确保参与各方能够通过加密进行安全通信。
数字证书提供以下服务：
加密：它们有助于保护交换的数据免受盗窃或篡改。
身份验证：验证其持有者 (人员、网站，甚至网络设备（如路由器) ）是否是他们声称的身份或身份。 通常情况下，身份验证是单向的（即源验证目标的身份），而双向的 TLS 身份验证也是可以实现的。
可针对多种用途颁发证书。 例如：Web 用户身份验证、Web 服务器身份验证、安全/多用途 Internet 邮件扩展 (S/MIME)、Internet 协议安全性 (IPsec) 和代码签名。
证书包含一个公钥，并将此公钥与持有相应私钥的个人、计算机或服务的身份联系起来。 客户端和服务器使用这些公钥和私钥在传输数据前加密数据。 对于 Windows 用户、计算机和服务，如果已在受信任的根证书存储中定义根证书，并且证书包含有效的证书路径，那么就可建立对 CA 的信任。 未被吊销（不在 CA 证书吊销列表 (CRL) 中）且未超过有效期的证书才是有效的证书。
下表描述了三种主要的数字证书类型。
| 类型 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 自签名证书 | 此类证书由创建它的应用程序进行签名。 | 费用（免费）。 | 客户端计算机和移动设备不会自动信任此类证书。 需要手动将此类证书添加到所有客户端计算机和设备上的受信任的根证书存储，但并非所有移动设备都允许更改受信任的根证书存储。 并非所有服务都支持自签名证书。 很难构建证书生命周期管理的基础结构。 例如，无法吊销自签名证书。 |
| 内部 CA 颁发的证书 | 此类证书由组织中的公钥基础结构 (PKI) 颁发。 例如，Active Directory 证书服务 (AD CS)。 有关详细信息，请参阅 Active Directory 证书服务概述。 | 允许组织颁发自己的证书。 比商业 CA 颁发的证书便宜。 |
增加了部署和维护 PKI 的复杂程度。 客户端计算机和移动设备不会自动信任此类证书。 需要手动将此类证书添加到所有客户端计算机和设备上的受信任的根证书存储，但并非所有移动设备都允许更改受信任的根证书存储。 |
| 商业 CA 颁发的证书 | 从受信任的商业 CA 购买的证书。 | 简化了证书部署，因为所有客户端、设备和服务器均自动信任此类证书。 | 成本。 需要提前计划，以最大程度地减少所需的证书数。 |
为证明证书持有者与其所声称的身份相符，证书必须准确地向其他客户端、设备或服务器标识证书持有人。 下表描述了这样做的三种基本方法。
| 方法 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 证书使用者匹配 | 证书的" Subject "字段包含主机的公用名称 (CN)。 例如，颁发给 www.contoso.com 的证书可用于网站 https://www.contoso.com。 | 与所有客户端、设备和服务兼容。 划分。 吊销主机的证书不会影响其他主机。 |
所需的证书数。 只能将证书用于指定的主机。 例如，即使服务安装在同一台服务器上，也不能将 www.contoso.com 证书用于 ftp.contoso.com。 复杂性： 在 Web 服务器上，每个证书都需要自己的 IP 地址绑定。 |
| 证书使用者可选名称 (SAN) 匹配 | 除了" Subject "字段之外，证书的" Subject Alternative Name "字段也包含多主机名列表。 例如：
|
便利性。 可以将同一证书用于多个单独域中的多个主机。 大多数客户端、设备和服务支持 SAN 证书。 审核和安全性。 你确切知道哪些主机能够使用 SAN 证书。 |
需要制定更多计划。 需要在创建证书时提供主机列表。 缺乏分隔。 不能在不影响证书中的所有主机的情况下选择性地撤销某些指定主机的证书。 |
| 通配符证书匹配 | 证书的 “使用者 ”字段包含通配符的公用名称 (*) 加上单个域或子域。 例如，*.contoso.com 或 *.eu.contoso.com。 *.contoso.com 通配符证书可用于：
|
灵活性。 请求证书时，无需提供主机列表，并且可以在将来可能需要的任意数量的主机上使用该证书。 | 无法将通配符证书与其他一级域名 (TLD) 一起使用。 例如，不能将 *.contoso.com 通配符证书用于 *.contoso.net 主机。 只能将通配符证书用于通配符级别的主机名。 例如，不能将 *.contoso.com 证书用于 www.eu.contoso.com。 或者，不能将 *.eu.contoso.com 证书用于 www.uk.eu.contoso.com。 旧版客户端、设备、应用程序或服务可能不支持通配符证书。 通配符不适用于扩展验证 (EV) 证书。 必须严格审核和控制。 如果通配符证书遭到入侵，将会影响指定域中的所有主机。 |
Exchange 中的证书
在服务器上安装 Exchange 2016 或 Exchange 2019 时，Exchange 将创建并安装两个自签名证书。 第三个自签名证书由 Microsoft Windows 为 Internet Information Services (IIS) 中的 Web 管理服务创建并安装。 这三个证书在 Exchange 管理中心 (EAC) 和 Exchange 命令行管理程序中可见，下表进行了详细介绍：
| 名称 | Comments |
|---|---|
| Microsoft Exchange | 此 Exchange 自签名证书具有以下功能：
|
| Microsoft Exchange Server 身份验证证书 | 此 Exchange 自签名证书用于 OAuth 服务器间身份验证和集成。 有关详细信息，请参阅 计划 Exchange Server 与 SharePoint 的集成和 Skype for Business。 |
| WMSVC | 此 Windows 自签名证书由 IIS 中的 Web 管理服务使用，用于启用远程管理 Web 服务器及其关联的网站和应用程序。 如果删除此证书，且未选择任何有效证书，那么 Web 管理服务将无法启动。 如果服务处于此状态，你可能无法安装 Exchange 更新程序，也无法从服务器卸载 Exchange。 有关如何更正此问题的说明，请参阅 事件 ID 1007 - IIS Web 管理服务身份验证 |
默认自签名证书的属性部分中介绍了这些自签名证书的属性。
下面介绍了需要考虑的有关 Exchange 中的证书的关键问题：
无需替换 Microsoft Exchange 自签名证书，即可加密组织中 Exchange 服务器和服务之间的网络流量。
必须使用其他证书，才能加密内外部客户端与 Exchange 服务器的连接。
必须使用其他证书，才能强制加密 Exchange 服务器和外部邮件服务器之间的 SMTP 连接。
Exchange Server 规划和部署的以下元素是满足证书要求的重要驱动因素：
负载均衡：是否计划终止负载均衡器或反向代理服务器上的加密通道、使用第 4 层或第 7 层负载均衡器以及使用会话相关性还是不使用会话相关性？ 有关详细信息，请参阅 Load Balancing in Exchange 2016（Exchange 2016 中的负载均衡）。
Namespace规划：存在哪些 Exchange 版本、是否使用绑定或未绑定命名空间模型，以及是否使用 拆分脑 DNS (基于内部访问和外部访问) 为同一主机配置不同的 IP 地址？ 有关详细信息，请参阅 Namespace Planning in Exchange 2016（Exchange 2016 中的命名空间计划）。
客户端连接：客户端将使用哪些服务 (基于 Web 的服务、POP、IMAP 等 ) ，涉及哪些 Exchange 版本？ 有关详细信息，请参阅下列主题：
Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2013（包含 Exchange 2013 的 Exchange 2016 共存环境中的客户端连接）
Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2010（包含 Exchange 2010 的 Exchange 2016 共存环境中的客户端连接）
Client Connectivity in an Exchange 2016 Coexistence Environment with Mixed Exchange Versions（包含混合 Exchange 版本的 Exchange 2016 共存环境中的客户端连接）
Exchange Server 中的椭圆曲线加密证书支持
从 Exchange Server 2024 年 4 月修补程序更新 (胡) 开始，Exchange Server 2016 和 Exchange Server 2019 支持对某些服务使用椭圆曲线加密 (ECC) 证书。
ECC 证书或椭圆曲线加密证书是一种数字证书，它使用椭圆曲线算法进行加密，与传统 RSA 证书相比，密钥长度较短，可提供更强的安全性。
警告
以下方案当前不支持使用 ECC 证书。 我们正在努力进行更新，以在未来支持这些方案：
- 无法在边缘传输服务器角色上分配 ECC 证书
- 可以将 ECC 证书分配给 POP 和 IMAP 服务，但不会使用它们
- 联合身份验证信任证书必须是 RSA 证书
- Exchange Server OAuth 证书必须是 RSA 证书
- 配置 了使用基于 AD FS 声明的身份验证 时，无法使用 ECC 证书
查看下一部分中的表，了解哪些服务可与 ECC 证书一起使用。
默认情况下，ECC 证书支持处于禁用状态，可以通过创建替代来启用。 执行命令后 New-SettingOverride ， (EMS) 打开新的 Exchange 命令行管理程序：
New-SettingOverride -Name "ECC Support" -Parameters @("Enabled=true") -Component "Global" -Reason "Support ECC" -Section "ECCCertificateSupport"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force
Exchange 服务的证书要求
下表介绍了可将证书分配给哪些 Exchange 服务。
| 服务 | 说明 | 支持的 ECC 证书 |
|---|---|---|
| IIS (HTTP) | 默认情况下，以下服务是以默认网站的名义在邮箱服务器上的客户端访问（前端）服务中提供，供客户端用来连接 Exchange：
因为只能将一个证书与网站相关联，所以证书中需要包含客户端用于连接这些服务的所有 DNS 名称。 为此，可以使用 SAN 证书或通配符证书。 |
是 |
| POP 或 IMAP | 用于 POP 或 IMAP 的证书与用于 IIS 的证书不同。 不过，为了简化管理，我们建议也在 IIS 证书中添加用于 POP 或 IMAP 的主机名，并对所有这些服务使用同一证书。 | 否 |
| SMTP | 在 Exchange 服务器上的前端传输服务中配置的一个或多个接收连接器接受来自客户端或邮件服务器的 SMTP 连接。 有关详细信息，请参阅接收连接器。 若要强制对 SMTP 连接进行 TLS 加密，可以对每个接收连接器单独使用证书。 证书必须包括 SMTP 客户端或服务器连接接收连接器时使用的 DNS 名称。 为了简化证书管理，不妨在一个证书中添加要为其提供 TLS 通信支持的所有 DNS 名称。 若要要求 相互 TLS 身份验证，其中源服务器和目标服务器之间的 SMTP 连接都经过加密和身份验证，请参阅 域安全性。 |
是 |
| 统一消息 (UM) | 有关详细信息，请参阅Deploying Certificates for UM。 注意：UM 在 Exchange 2019 中不可用。 |
是 |
| 使用 Microsoft 365 或 Office 365 进行混合部署 | 有关详细信息，请参阅Certificate Requirements for Hybrid Deployments。 | 是 |
| 安全/多用途 Internet 邮件扩展 (S/MIME) | 有关详细信息，请参阅邮件签名和加密的 S/MIME。 | 否 |
*Kerberos 身份验证和 Kerberos 加密适用于 Exchange 管理中心和 Exchange 命令行管理程序中进行的远程 PowerShell 访问。 因此，只要直接连接 Exchange 服务器（而不是负载均衡的命名空间），就无需将证书配置为用于远程 PowerShell。 若要使用远程 PowerShell 从非域成员的计算机连接到 Exchange 服务器，或者从 Internet 进行连接，需要配置证书以用于远程 PowerShell。
Exchange 证书的最佳做法
尽管组织的数字证书的配置会因其特定需要而有所不同，但包含有关最佳做法的信息可以帮助您选择适合您的数字证书配置。
使用尽可能少的证书：很可能，这意味着使用 SAN 证书或通配符证书。 在与 Exchange 的互操作性方面，两者的功能相当。 决定是使用 SAN 证书还是使用通配符证书时，更多地是要考虑每种证书类型的主要功能或限制（实际或想象中的），如 数字证书概述部分所述。
例如，如果所有公用名称都在 contoso.com 这同一级别，那么 SAN 证书或通配符证书都可以使用。 不过，如果需要将证书用于 autodiscover.contoso.com、autodiscover.fabrikam.com 和 autodiscover.northamerica.contoso.com，则需要使用 SAN 证书。
将来自商业 CA 的证书用于客户端和外部服务器连接：尽管你可以将大多数客户端配置为信任任何证书或证书颁发者，但使用商业 CA 中的证书与 Exchange 服务器的客户端连接要容易得多。 无需在客户端上进行配置，即可信任商业 CA 颁发的证书。 许多商业 CA 提供专为 Exchange 配置的证书。 可以使用 EAC 或 Exchange 命令行管理程序生成适用于大多数商业 CA 的证书请求。
选择正确的商业 CA：比较 CA 之间的证书价格和功能。 例如：
验证连接 Exchange 服务器的客户端（操作系统、浏览器和移动设备）是否信任 CA。
验证 CA 是否支持你所需的证书类型。 例如，并非所有 CA 都支持 SAN 证书，CA 可能会限制在 SAN 证书中使用的公用名称数量，或 CA 可能会根据 SAN 证书中的公用名称数量收取额外费用。
确定 CA 是否提供宽限期，以便你可以在 SAN 证书颁发后免费向其添加其他公用名称。
验证证书的许可证是否允许在所需数量的服务器上使用证书。 一些 CA 只允许在一台服务器上使用证书。
使用 Exchange 证书向导：创建证书时的常见错误是忘记要使用的服务所需的一个或多个公用名称。 Exchange 管理中心中的证书向导将帮助你在证书请求中添加正确的公用名称列表。 使用证书向导，可以指定将使用证书的服务，并添加这些服务的证书中必须包含的公用名称。 部署初始 Exchange 2016 或 Exchange 2019 服务器集并确定用于部署的不同服务的主机名时，请运行证书向导。
尽可能少地使用主机名：最小化 SAN 证书中的主机名数可降低证书管理所涉及的复杂性。 如果证书的预期用途不需要，则不必在 SAN 证书中添加各个 Exchange 服务器的主机名。 通常情况下，只需添加向使用证书连接 Exchange 的内部客户端、外部客户端或外部服务器显示的 DNS 名称。
对于名为 Contoso 的简单 Exchange Server 组织，这是所需的最小主机名的假设示例：
mail.contoso.com：此主机名涵盖与 Exchange 的大多数连接，包括 Outlook、Outlook 网页版、OAB 分发版、Exchange Web 服务、Exchange 管理中心和 Exchange ActiveSync。
autodiscover.contoso.com：支持自动发现的客户端（包括 Outlook、Exchange ActiveSync 和 Exchange Web Services 客户端）需要此特定主机名。 有关详细信息，请参阅自动发现服务。
默认自签名证书的属性
下表介绍了 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 |
| 使用者可选名称 (CertificateDomains) |
<ServerName> (例如 Mailbox01) <ServerFQDN> (例如，Mailbox01.contoso.com) |
无 |
WMSvc-<ServerName>例如， () WMSvc-Mailbox01 |
| 具有私钥 (HasPrivateKey) | 是 (True) | 是 (True) | 是 (True) |
| PrivateKeyExportable* | False | True | True |
| EnhancedKeyUsageList* | Server 身份验证 (1.3.6.1.5.5.7.3.1) | Server 身份验证 (1.3.6.1.5.5.7.3.1) | Server 身份验证 (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 |
无 | 无 |
| IsSelfSigned | True | True | True |
| 颁发者 |
CN=<ServerName>例如， () CN=Mailbox01 |
CN=Microsoft Exchange Server Auth Certificate |
CN=WMSvc-<ServerName>例如， () CN=WMSvc-Mailbox01 |
| NotBefore | 安装 Exchange 时的日期/时间。 | 安装 Exchange 时的日期/时间。 | 安装 IIS Web 管理服务时的日期/时间。 |
| 到期日期 (NotAfter) | 5 年后 NotBefore。 |
5 年后 NotBefore。 |
10 年后 NotBefore。 |
| 公钥大小 (PublicKeySize) | 2048 | 2048 | 2048 |
| RootCAType | 注册表 | 无 | 注册表 |
| 服务 | IMAP、POP、IIS、SMTP | SMTP | 无 |
*这些属性在 Exchange 命令行管理程序的标准视图中不可见。 若要查看，需要使用 Format-Table 或 Format-List cmdlet 指定属性名（确切的名称或通配符匹配）。 例如：
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 |
Subject Type=End Entity |
不适用 |
| 指纹算法 | sha2561 | sha2561 | sha2561 |
1 适用于 Exchange 2016 累积更新 22 或更高版本和 Exchange 2019 累积更新 11 或更高版本的全新安装。 有关详细信息，请参阅 在设置过程中创建的 Exchange Server 2019 和 2016 证书使用 SHA-1 哈希。
通常情况下，不使用 Windows 证书管理器来管理 Exchange 证书（使用 Exchange 管理中心或 Exchange 命令行管理程序）。 请注意，WMSVC 证书不是 Exchange 证书。