证书在 Exchange 2007 Server 中的使用

如上所述，Exchange 2007 中的许多组件都使用证书。通常情况下，所有通过证书保护的内部 Exchange 数据路径都不需要公用 CA 颁发的证书。

所有内部 SMTP 和 UM 通信都通过在运行 Exchange 2007 Server 安装程序时安装的自签名证书进行保护。尽管每年应使用 New-ExchangeCertificate cmdlet 续订这些证书，但是，不需要公用 CA 颁发的证书也可运行默认的内部 Exchange 邮件组件。

注意：
Exchange 创建的自签名证书在一年后过期。即使自签名证书过期，依赖默认自签名证书的内部组件仍会继续运行。但是，自签名证书过期后，会在事件查看器中记录事件。最佳做法是在过期之前续订自签名证书。

Exchange 2007 包括一组用于创建、申请和管理 TLS 证书的 cmdlet。有关这些 cmdlet 的详细信息，请参阅本主题后面的证书 Cmdlet。 默认情况下，这些证书为自签名证书。如本主题前面所述，自签名证书是由其创建者签署的证书。在 Exchange 2007 中，自签名证书是由运行 Microsoft Exchange 的计算机使用基本 Windows 证书 API (CAPI) 创建的。因为证书是自签名证书，所以此类证书的可信度通常要低于 CA 生成的证书。因此，建议只对下列内部方案使用自签名证书：

• 集线器传输服务器之间的 SMTP 会话：证书只用于对 SMTP 会话进行加密。身份验证由 Kerberos 协议提供。
• 集线器传输服务器与边缘传输服务器之间的 SMTP 会话：证书用于对 STMP 会话进行加密以及用于进行直接信任身份验证。
• 边缘传输服务器与 Active Directory 之间的 EdgeSync 同步：在 Microsoft Exchange EdgeSync 服务将数据从 Active Directory 复制到边缘传输服务器上的 ADAM 实例之后，使用证书对边缘传输服务器上的 ADAM 实例与内部 Active Directory 服务器之间的 LDAP 通信会话进行加密。
• 统一消息通信：使用证书对 UM 服务器和 UM IP 网关、IP 专用交换机 (PBX) 和运行 Office Communications Server 2007 的计算机之间的会话初始协议 (SIP) 和实时传输协议 (RTP) 通信进行加密。还会在将语音邮件或传真邮件从 UM 服务器提交到集线器传输服务器时，使用证书对 SMTP 通信进行加密。
• 仅供内部客户端访问的客户端访问服务器。

内 部 Exchange 组件可以依赖自签名证书，因为这些证书不用于身份验证。大多数 Exchange 组件的身份验证由 Kerberos 或 NTLM 提供。在边缘传输服务器与集线器传输服务器之间的通信中，将使用直接信任身份验证。直接信任身份验证由证书提供，并且边缘传输服务器的公钥存储在 Active Directory 中（Active Directory 是受信任的存储）。否则，使用自签名证书提供短周期密钥，来对 Exchange 组件之间的数据路径进行加密。

但是，如果外部客户端从 Internet 访问 Exchange 所驻留的网络，则要求进行传统的证书信任验证。最佳做法是使用公用 CA 颁发的证书进行信任验证。实际上，如果要求进行证书身份验证，使用自签名证书并不是最佳做法，强烈建议不要这样做。对于下列情况，建议使用公用 CA 颁发的证书：

• POP3 和 IMAP4 客户端访问 Exchange
• Outlook Web Access
• Outlook Anywhere
• Exchange ActiveSync
• 自动发现
• 域安全性

上述所有情况的最佳做法是使用所有客户端默认情况下信任的公用 CA。

使用 New-ExchangeCertificate cmdlet 根据将颁发证书的第三方公用 CA 的规范生成证书请求。

有关详细信息，请参阅下列主题：

• New-ExchangeCertificate
• 创建 TLS 证书或证书请求
• Exchange 2007 学习课程 - 通过第三方 CA 生成证书
  

  注意：
  Wiki 和博客的内容及其 URL 可能随时更改，恕不另行通知。

本部分的剩余内容将介绍这些相关信息：如何确定必须购买的公用证书类型，以及是否必须购买多个证书来帮助保护组织中用于访问 Exchange 2007 的客户端。

确定公用 CA 颁发的、适合您的部署的证书类型和证书数目

---

如何选择相应公用 CA 颁发的、适合您的组织的证书，具体要取决于下列因素：

• 客户端对证书中的通配符名称的支持   请回答下列问题：将支持什么客户端？如上所述，此上下文中的“客户端”是指从 Internet 访问 Exchange 的客户端。
• 组织的命名空间   如何配置面向 Internet 的 Internet Information Services (IIS) 命名空间？
• 证书来源   将从哪里获取证书？所选的公用 CA 是否支持在“Subject”或“Subject Alternative Name (SAN)”字段中使用通配符？如果不支持，是否支持使用 SAN？

下列各部分将更为深入地了解这些因素。

客户端对证书中的通配符名称的支持

---

通配符名称可以在 X.509 证书的主题或 SAN 扩展中使用。有关通配符名称的详细信息，请参阅本主题后面的了解证书属性以及 Exchange 2007 如何使用这些证书属性中的“CertificateDomains”。

确定了组织将支持的客户端之后，需要确定客户端是否支持在服务器证书（客户端要连接到的）中使用通配符名称的证书。

如 果客户端支持在证书中使用通配符名称，可以显著简化组织的总体证书规划。如果所有客户端均支持证书中的通配符名称，并且组织使用单个域名，则不必考虑证书 部署策略的命名空间规划。可以创建一个支持包含通配符的命名空间的证书。例如，如果运行 Outlook Web Access 的客户端使用 mail.contoso.com/owa 访问其邮件，而 POP3 客户端使用 pop.contoso.com 访问其邮件，通配符主题为 *.contoso.com 的单个证书将同时支持这两个客户端。

下列 Microsoft 客户端支持证书中的通配符名称：

• Outlook
  

  注意：
  跨运行客户端访问角色的 Exchange 服务器部署通配符证书时，自动发现设置需要一些配置以使 Outlook 2007 客户端能够连接成功。要了解有关此问题以及解决方法的详细信息，请参阅通配符证书导致 Outlook Anywhere 的客户端连接问题。

• Internet Explorer (Outlook Web Access)
• Exchange 边缘传输服务器（域安全性）

要点：
如果证书中使用通配符名称，运行 Windows Mobile 5.0 的客户端不支持到服务器的加密通道。

如果组织支持的客户端不支持服务器证书中的通配符名称，并且可支持多个客户端命名空间，则必须

1. 购买 SAN 扩展中包含多个名称（例如 mail.contoso.com、pop.contoso.com 和 mobile.contoso.com）的证书。
2. 为客户端将连接到的命名空间中的每个实体购买一个证书。

规划组织的命名空间

---

所有客户端都需要连接到的 URL 或完全限定的域名 (FQDN)。客户端连接到的每个路径必须与包含客户端所连接到的主机的主机名、NetBIOS 名称、FQDN 或公用名的有效证书相关联。确定证书中要包含的名称的列表就是“规划命名空间”的过程。

通常情况下，对于支持许多不同客户端并跨越包含多个服务器的多个区域的大型组织，规划命名空间要比规划小型组织的命名空间更加复杂。

必须了解如何规划证书命名空间，以便了解用于帮助保护 Exchange 2007 的入站连接的证书在 SAN 扩展中要包含的主机名。

有关详细信息，请参阅了解 Exchange Server 2007 的命名空间规划。

从哪里获取证书

---

如上所述，对于外部客户端访问，建议从第三方公用 CA 购买证书。

在评估证书颁发机构时，请考虑以下条件：

• CA 是否允许在证书中使用通配符名称？如果客户端可以支持证书中的通配符名称，从 CA 购买支持通配符名称的证书是部署安全客户端最简单的方法。
• CA 是否支持 SAN 扩展？如果满足下列条件，意味着需要使用支持 SAN 中的多个名称的证书：
  
  • 对于不支持证书中的通配符名称的客户端，必须提供支持。
  • 有客户端必须连接到的多个主机路径。
  Microsoft 与公用 CA 合作来提供统一通信证书。有关支持统一通信证书的 CA 的最新列表，请参阅 Microsoft 知识库文章 929395 Exchange 2007 和 Communications Server 2007 的统一通信证书合作伙伴。
• CA 是否提供高级别的真实性检查？有些 CA 的开销比较低，而有些 CA 每年则需要为证书花费数百美元。由于您依赖该证书的完整性来验证组织的入站通信，所以建议您不要只根据成本的高低来选择公用 CA。在做出决定之前，请认真评估并比较每个 CA 提供的服务以及每个 CA 的信誉。

返回顶部

如上所述，证书字段是 X.509 证书本身的签名数据中的属性。本部分介绍 Microsoft Exchange 服务使用的并显示在 Get-ExchangeCertificate cmdlet 输出中的证书字段。

其中某些字段还是在使用 New-ExchangeCertificate cmdlet 创建新的证书或证书请求时可以设置的参数。有关 New-ExchangeCertificate cmdlet 的详细信息，请参阅 New-ExchangeCertificate。

本部分中的每个证书字段将根据 Get-ExchangeCertificate cmdlet 的输出列出。本部分中的每个 Exchange 证书字段名将映射到 X.509 证书扩展名。

Subject

---

该字段标识证书的主题。Subject 是一个 X.500 字符串，通常代表用于访问使用该证书的服务的单个名称。New-ExchangeCertificate cmdlet 创建证书时，如果未显式提供主题，Subject 将是在运行 New-ExchangeCertificate cmdlet 时，DomainName 参数上列出的第一个值。下列 X.500 字段可能会出现：

• C = 国家/地区
• ST = 省/市/自治区
• L = 位置
• O = 组织
• OU = 组织单位
• CN = 公用名

在为第三方 CA 生成证书请求时，其中某些字段是必需的。有关 Subject 字段的详细说明，请参阅创建 TLS 证书或证书请求。

如果在 Exchange 前面运行 Microsoft Internet Security and Acceleration (ISA) Server 2006 进行桥接，请务必阅读博客文章包含多个 SAN 条目的证书可能会中断 ISA Server Web 发布，了解有关主题名称和 ISA Server 行为的详细信息。

注意：
Wiki 和博客的内容及其 URL 可能随时更改，恕不另行通知。

Exchange 在没有任何用户参数的情况下生成自签名证书时，将创建一个主题名称为 CN=hostname 的证书。

X.509 证书扩展名也是 Subject。

通过在 New-ExchangeCertificate cmdlet 中指定 SubjectName 参数，可以设置 Subject 字段。

CertificateDomains

---

CertificateDomains 字段标识与证书相关联的所有 DNS 域名。DNS 域名可以在 Subject 的公用名 (cn=) 属性中或证书的 SAN 扩展中。Get-ExchangeCertificate cmdlet 的输出显示 Subject 字段中的域与 SAN 中发现的任何域的联合。

在 CertificateDomains 字段中发现的值可能包含用于访问服务器的主机名或 FQDN。若要使用证书，客户端用于连接到服务器的 FQDN 必须出现在证书的 CertificateDomains 字段中。

例如，如果客户端要使用 POP3 连接到服务器名称为 mail.fourthcofee.com 的服务器，与 POP3 设置相关联的证书可能在其 CertificateDomains 字段中包含 mail.fourthcofee.com。

您可能还会发现包含通配符名称（诸如 *.fourthcofee.com）的证书。该域是可接受的域。但是应注意，某些旧版客户端和移动设备不支持证书中的通配符名称，因此，可能不支持使用通配符域。

注意：
SAN 字段不会直接通过 Exchange 公布。只能在 MMC 的证书管理器中或通过 Internet Information Services (IIS) 管理器查看该字段。也可以在 IIS 管理器中查看绑定到网站上的证书，例如 IIS 用于 Outlook Web Access、Exchange ActiveSync 或自动发现的证书。

有关如何在证书中使用 SAN 和通配符名称的详细说明，请参阅创建 TLS 证书或证书请求。此外，在 Exchange 工作组博客 Exchange 2007 学习课程：通过第三方 CA 生成证书 中，提供了有关如何创建包含多个 SAN 的证书请求的可行建议。

注意：
Wiki 和博客的内容及其 URL 可能随时更改，恕不另行通知。

X.509 证书扩展名是 Subject Alternative Name，但是，如上所述，Get-ExchangeCertificate cmdlet 的输出还会将 Subject 证书扩展中包含的值添加到 CertificateDomains 字段的名称列表中。

通过指定 New-ExchangeCertificate cmdlet 的 DomainName 和 Subject 参数，可以设置 CertificateDomains 字段。

如上所述，证书属性是属于证书或私钥的元数据的属性。某些属性是证书或私钥固有的（例如证书的指纹），但许多属性即使在证书不重新签署的情况也可更改。

除了 Thumbprint 属性之外，没有任何 Exchange 证书属性与 X.509 证书扩展相对应。

本部分将介绍证书属性。

Windows、Windows Mobile 和各种第三方操作系统包括一组内置的第三方公用根 CA。如果信任由这些第三方公用根 CA 颁发的证书，则可以验证由这些 CA 颁发的证书。

如果符合下列条件，则自动信任：

• 组织使用默认 Windows 安装，
• 组织中使用的客户端软件和移动设备也信任内置的第三方公用根 CA，

在这种情况下，不需要进行其他信任配置。

私有受信任的根证书颁发机构

---

私有受信任的根 CA 是已通过私有 PKI 或内部 PKI 部署的根 CA。例如，组织部署了包含其自己的根证书的内部 PKI 后，必须进行其他信任配置。

通常情况下，最好不要对支持传入组织的外部连接的客户端应用程序使用私有 PKI 颁发的证书。

使用私有根 CA 时，必须更新所有要求进行证书身份验证的设备、客户端和 Windows 操作系统上的 Windows“受信任的根”证书存储。

可以使用两种方法配置信任：直接根信任和交叉证书。

直接根信任

---

如 果需要信任某个已由私有根 CA 颁发的证书，可以手动将该根证书添加到运行 Windows 的计算机上的“受信任的根”证书存储中。在某些情况下，还可以将根证书添加到移动客户端的受信任根存储中。有关如何手动向运行 Windows 的计算机上的本地证书存储添加证书的详细信息，请参阅 MMC 中证书管理器的帮助文件。有关如何在 Windows Mobile 设备上安装证书的详细信息，请参阅如何在基于 Windows Mobile 的设备上安装根证书。

要点：
可能无法在用户将用于访问 Exchange 的所有计算机和设备上安装证书。例如，某些用户可能会尝试从网亭或朋友的计算机访问 Outlook Web Access。在这种情况下，用户将收到警告，但是不会阻止用户访问自己的邮件。这实际上是在纵容用户忽略证书警告，所以不是最佳做法。因此，最佳做法是 使用受信任的第三方 CA 颁发的证书。

交叉证书

---

当 一个 CA 签署由另一个 CA 生成的证书时，将出现交叉证书。交叉证书使用一个 PKI 构建对另一个 PKI 的信任。如果已拥有自己的 PKI，即不必对另一个私有 PKI 的根 CA 使用直接手动信任，可以为根 CA 下的其他 CA 创建交叉证书。在这种情况下，会由于交叉证书最终将链回到受信任根 CA 而建立信任。

特 定服务（例如 SMTP/TLS 方案中的 Microsoft Exchange 传输服务或 HTTP 方案中的 IIS）在检索证书时将验证证书链和证书。证书验证是一个确认证书的许多属性的过程。其中的大部分属性可以在本地计算机上由申请该证书的应用程序进行确 认。例如，该证书的预期用法、过期日期以及类似的属性都可以在 PKI 上下文以外进行验证。但是，对尚未吊销的证书的验证必须通过颁发该证书的 CA 进行验证。因此，大部分 CA 制作了公开的证书吊销列表 (CRL)，用来验证吊销状态。

为成功使用证书进行身份验证，所使用的 CA 的 CRL 必须可供对客户端进行身份验证的服务使用。如果吊销检查失败，身份验证服务也将失败。

身份验证服务器必须可以访问外部 CA 的 CRL。

所 有公用 CA 都包含组织服务器可以联系的公开 CRL。在某些情况下，私有内部 PKI 的 CRL 仅适用于轻型目录访问协议 (LDAP)。大多数情况下，对于公用 CA，其 CRL 是使用 HTTP 进行发布的。确保配置了适当的出站端口和代理，以允许服务器和客户端与 CRL 联系。通过在 MMC 中打开证书并查看 CRL Distribution Points 字段，可确定给定 CRL 分发点接受的协议。

在 某些情况下，可能需要公开颁发证书的 CA 的 CRL。例如，如果要部署域安全性，必须了解的是，即使边缘传输服务器从您自己的组织检索证书，也可以验证证书链来验证证书。因此，您的 CA 的 CRL 必须可供您自己的边缘服务器使用。另外，您与之交换域安全电子邮件的所有合作伙伴都必须能够访问颁发证书的 CA 的 CRL。

若要验证特定 Exchange 服务器的 PKI 和代理配置，请使用 Certutil.exe 验证服务器证书的证书链。Certutil.exe 是一个命令行工具，在 Windows Server 操作系统中作为证书服务的一部分安装。有关详细信息，请参阅如何测试 PKI 和代理配置。

返回顶部

在早期版本的 Exchange Server 中，所有证书管理均通过 IIS 和 MMC 中的证书管理器来完成。在 Exchange 2007 中，通过在 Exchange 命令行管理程序中使用下列 ExchangeCertificate cmdlet，可以执行大多数与 Exchange 有关的证书管理任务：

• New-ExchangeCertificate   此 cmdlet 可生成自签名证书和证书颁发机构的证书请求。
• Import-ExchangeCertificate   此 cmdlet 可导入以前导出的证书并导入 CA 生成的证书文件。
• Export-ExchangeCertificate   此 cmdlet 可导出证书，以便进行备份或在多个服务器上使用。
• Enable-ExchangeCertificate   此 cmdlet 可对证书启用特定的服务。
• Get-ExchangeCertificate   此 cmdlet 可显示证书的属性。
• Remove-ExchangeCertificate   此 cmdlet 可将证书从 Exchange 服务器和本地证书存储中删除。

有关如何创建证书颁发机构的证书请求的详细信息，请参阅创建 TLS 证书或证书请求。

下列各部分提供的简短示例用于说明如何使用 ExchangeCertificate cmdlet 执行常见的证书任务。有关详细信息和示例，请参阅全局 Cmdlet 中的 ExchangeCertificate cmdlet 帮助。

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

Enable-ExchangeCertificate <thumbprint>

创建证书请求并安装受信任的证书

---

安装公用第三方证书的过程比较复杂。必须生成证书请求，导入颁发的证书以及所有必要的 CA 证书，然后使颁发的证书发挥其预期用途。

本部分举例说明如何对证书启用 POP3 服务。在该示例中，客户端通过连接到 FQDN popserver.fourthcoffee.com，连接到 POP3 服务。

证书请求

---

因为生成的证书来自于公用第三方 CA，所以必须先通过运行以下命令生成证书请求：

 

 

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

如果证书请求已正确生成，将在系统驱动器的根目录中创建证书请求文件 (.cer 或 .der)，并且 Exchange 命令行管理程序将显示请求的指纹。

注意：
提供商返回的证书将支持证书请求文件使用的不同扩展名，诸如 .der 或 .cer。这些扩展名代表证书文件中使用的编码方法。默认情况下，New-ExchangeCertificate 请求将创建 Base64 编码的文件 (.cer)。使用 BinaryEncoded 参数开关来创建 .der 文件。

在先前的命令中，PrivateKeyExportable 参数设置为 $True，这样该证书可以随私钥一起导出，以便在可能需要使用相同 FQDN 访问的多个 Exchange 服务器上使用。例如，多个客户端访问服务器可能会进行负载平衡，以支持 POP3 连接。

注意：
PrivateKeyExportable 参数是可选的。只有在生成受信任 CA 的证书请求时，才应指定该参数。通过将 PrivateKeyExportable 参数设置为 $True，可以移动并存档证书以及相关联的密钥。不必使用自签名证书即可执行该操作。

先前的命令还将 Subjectname 参数指定为 X.500 名称。大多数第三方 CA 要求为证书的主题名称指定有效的 X.500 名称。大多数 CA 至少要求 organizationName (o=) 字段中列出的组织拥有 Web 服务器的 commonName (cn=) 中出现的域名。

请求完成后，可以将请求文件提交给证书供应商以获取证书。

注意：
Get-ExchangeCertificate cmdlet 返回证书以及仍在申请的证书。为了区分这两种证书，证书请求包含 CertificateRequest 属性，用于显示证书请求文件中存储的输出。如果意外地删除了证书请求文件或在没有该参数的情况下生成请求，上述输出可能很有用。CertificateRequest 数据是 base64 编码的数据，可以复制到文件中并发送给 CA 以申请证书。

导入证书

---

CA 返回证书后，您必须将证书导入到 Exchange 服务器。若要正确导入使用 New-ExchangeCertificate cmdlet 生成其请求的证书，请运行以下命令：

 

 

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

如果证书已成功导入，该命令将返回可用于启用特定服务的证书指纹。

要点：
必须将证书导入到生成证书请求的同一台计算机上。此外，不要使用 MMC 中的证书管理器导入 Exchange 证书。

启用证书

---

启用证书后，可以指定使用特定证书的服务。以下命令用于对颁发的证书启用 POP3 服务：

 

 

Enable-ExchangeCertificate <thumprint> -Services:"POP"

可以通过运行以下命令同时导入和启用证书：

 

 

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

验证证书安装

---

若要确认所有必要的步骤是否已完成以及证书是否已安装并使用，请运行以下命令：

 

 

Get- ExchangeCertificate <thumbprint> | fl *

注意：
如果运行的是 Exchange 2007 SP1 或更高版本，不要在命令参数中包含星号 (*)。

该命令的输出返回的数据类似于以下内容：

 

 

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

检查该命令的输出，以验证下列信息是否正确：

• 期望存在的域名在 CertificateDomains 字段中列出。
• HasPrivateKey 属性设置为 True。
• RootCAType 属性已正确设置。有关 RootCAType 属性的详细信息，请参阅本文档前面的证书属性。
• 对证书启用所需的服务。
• “状态”设置为 Valid。

可以对证书启用诸如 POP、IMAP、IIS 和 SMTP 等服务。服务不是证书本身中的字段，而是证书的元数据属性。因此，不必使证书失效即可进行更改。

启用服务后，将对其他组件（例如在 IIS 元数据库中）、文件系统或 IMAP4 和 POP3 设置进行配置更改。本部分将介绍在通过运行 Enable-ExchangeCertificate cmdlet 启用给定的服务时进行的配置更改。

POP 和 IMAP

---

将 POP 和 IMAP 作为附加服务添加到证书中时，POPSettings 对象或 IMAPSettings 对象的 x509CertificateName 属性将进行更新，以使该域包含在证书主题中。

例如，若要验证 POPSettings 对象是否已更新，请运行以下命令：

 

 

Get-POPSettings | fl *

注意：
如果运行的是 Exchange 2007 SP1 或更高版本，不要在命令参数中包含星号 (*)。

STARTTLS 是启动安全 TLS 会话的 SMTP 动词。只有运行 Exchange 的计算机上存在有效的证书时，Exchange 才会公布 STARTTLS。

为了公布或使用 STARTTLS，Exchange 将根据 FQDN 选择证书并在证书的 CertificateDomains 字段中选择一个匹配值。FQDN 基于下列信息：

• 出站 STARTTLS   根据发送连接器上的 FQDN 值选择证书。
• 入站 STARTTLS   根据接收连接器上的 FQDN 值选择证书。
  

  注意：
  对于出站 STARTTLS 和入站 STARTTLS，如果未指定连接器的 FQDN，Exchange 服务器的物理 FQDN 将用于该匹配。

确定了 FQDN 后，Exchange 将在主机计算机上的“个人”证书存储中搜索所有有效的证书。如果满足下列所有要求，证书则可用于 TLS：

• Enhanced Key Usage 字段包含服务器身份验证对象标识符（也称为 OID）或为空。
• PKI 证书扩展列出 RSA 密钥，至少为 1024 位。
• 证书将验证证书链，直至受信任的根，或证书是自签名证书。
• 证书和证书链通过吊销检查。
• 私钥存在并且可用。
• 私钥未存储在可移除设备中。
• 私钥未使用密码进行保护。

如果发现多个有效的证书，Exchange 将根据以下条件选择证书：

• NotBefore 字段中的值   Exchange 选择最新的有效证书。
• 受信任的 CA 颁发的证书与自签名证书   与自签名证书相比，Exchange 优先选择受信任的 CA 颁发的证书。

在大多数情况下，与自签名证书相比，无论证书期限如何，Exchange 都会优先选择受信任的 CA 颁发的证书。如果未发现有效的证书，则不会公布 STARTTLS。

X-AnonymousTLS 用于帮助保护两个集线器传输服务器之间以及集线器传输服务器与边缘传输服务器之间的通信。在 Exchange 2007 SP1 中，证书选择过程已得到简化，如果未找到任何证书，将为会话生成一个临时加密密钥。

Exchange 搜索内部传输证书。如果找不到有效的内部传输证书，Exchange 将搜索有效的 CA 证书。

因此，对于使用 Kerberos 协议进行身份验证的集线器传输服务器之间的通信，即使没有有效的内部传输证书，SMTP 会话也不会失败。SMTP 会话使用临时加密密钥进行加密。在这种情况下，将记录事件，并且必须在生成该事件的计算机上运行没有参数的 New-ExchangeCertificate cmdlet，以创建新的内部传输证书。

对于集线器传输服务器到边缘传输服务器的通信，如果为组织订阅了边缘传输服务器，并且未找到有效的内部传输证书，会话将失败，并记录错误。在这种情况下，必须在生成该事件的计算机上运行没有参数的 New-ExchangeCertificate cmdlet，然后再次运行 Microsoft Exchange EdgeSync 服务。

与 SMTP STARTTLS 的证书选择过程相同，在 POP3 和 IMAP4 的证书选择过程中，Exchange 必须选择 FQDN 并根据 CertificateDomains 字段中的匹配值找到证书。根据 POP3 或 IMAP4 服务设置中的 X509CertificateName 属性选择 FQDN。可以通过运行 Get-POPSettings cmdlet 或 Get-IMAPSettings cmdlet，查看 X509CertificateName 属性。有关详细信息，请参阅 Get-POPSettings 和 Get-IMAPSettings。

Exchange 2007 SP1 中 POP3 和 IMAP4 的选择过程与 SMTP STARTTLS 的过程相同。

注意：
在 Exchange 2007 RTM 中，POP3 和 IMAP4 的证书选择过程中主要有两个例外情况。受信任的 CA 颁发的证书并不优先于自签名证书。Exchange 2007 将选择最新的证书。此外，在 Exchange 2007 RTM 中，POP3 和 IMAP4 不支持证书中的通配符域。这意味着如果 POP3 设置或 IMAP4 设置的 X509CertificateName 属性设置为 mail.fourthcoffee.com，Exchange 2007 将不支持只包含 *.fourthcoffee.com 作为证书域的证书。

如 果 Microsoft Exchange 统一消息服务是在安全模式下启动的，它将查询本地“个人”证书存储，以找到可用于 TLS 以启用加密的有效证书。Microsoft Exchange 统一消息服务将首先查找私有 PKI 或公用 CA 颁发的有效证书。如果未找到适合的证书，将查找自签名证书。如果未找到任何 PKI 证书、公用证书或自签名证书，Microsoft Exchange 统一消息服务将创建在安全模式下启动时要使用的自签名证书。如果 UM 服务器在非安全模式下启动，则不需要任何证书。

一旦使用了证书或证书已更改，将记录在安全模式下启动时所使用的证书的所有详细信息。所记录的一些详细信息包括：

• 颁发者名称
• 序列号
• Thumbprint

指纹是安全哈希算法 (SHA1) 哈希值，可用于唯一标识所使用的证书。可以将 Microsoft Exchange 统一消息服务在安全模式下启动时所使用的证书从本地证书存储中导出，之后将此证书导入网络中的统一消息 IP 网关和 IP PBX 上受信任的证书存储中。

发现并使用适合的证书之后，在所使用的证书过期前一个月，Microsoft Exchange 统一消息服务将记录一个事件。如果此时不对证书进行任何更改，则在证书过期前的每一天以及在证书过期后的每一天，Microsoft Exchange 统一消息服务都会记录事件。

如果统一消息服务器要查找供相互 TLS 在建立加密通道时使用的证书，将在受信任的根证书存储中查找。如果有多个有效证书并且来自不同颁发者，则统一消息服务器将选择距离证书过期时间最长的有效 证书。如果存在多个证书，则统一消息服务器将基于颁发者和证书的过期日期来选择证书。统一消息服务器按照以下优先顺序查找有效的证书：

1. 过期期限最长的 PKI 证书或公用证书。
2. 过期期限最短的 PKI 证书或商业证书。
3. 过期期限最长的自签名证书。
4. 过期期限最短的自签名证书。

返回顶部