通过

证书在 Exchange 2007 Server 中的使用

  • 项目

 

适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上一次修改主题： 2008-05-19

Microsoft Exchange Server 2007 使用证书来帮助保护许多电子邮件通信路径的安全。本主题将全面介绍证书在 Exchange 2007 中的使用。本主题包含的内容有：

  • 如何在 Exchange 2007 中使用证书。

  • 如何确定是否应购买第三方公用证书颁发机构 (CA) 颁发的证书以及何时只使用默认的自签名证书即可。

  • Exchange 2007 组件如何使用证书属性以及证书属性如何与 X.509 证书扩展字段相关联。

  • 证书信任和验证。

  • 如何创建、导入和启用 Exchange 2007 证书。

  • Exchange 组件如何从“个人”计算机存储中选择证书。

本主题中的每一部分都包含与证书有关的 Exchange 2007 文档的引用和链接。

致谢   本部分内容基本上是从技术支持工程师 Stuart Presley 收集并提供的 Microsoft 内部说明和文档改编的。

目录

  • 使用证书对会话进行加密或身份验证的 Exchange 2007 组件

  • 如何确定何时使用公用 CA 颁发的证书以及何时使用自签名证书

  • 了解证书属性以及 Exchange 2007 如何使用这些证书属性

  • 证书信任和验证

  • 创建、导入和启用证书

  • 证书选择

  • 详细信息

使用证书对会话进行加密或身份验证的 Exchange 2007 组件

Exchange 2007 使用 X.509 证书与通信的传输层安全性 (TLS) 和安全套接字层 (SSL) 传输通道协商 HTTPS、SMTP、POP 以及 IMAP 等协议。

TLS 是 Internet 工程任务组 (IETF) 标准协议，可帮助在通过网络进行通信的两个应用程序之间实现通信私密性和安全性。TLS 对通信进行加密，并使客户端对服务器进行身份验证，也可以使服务器对客户端进行身份验证。TLS 是 TLS 所基于的 SSL 协议的一个更安全的版本。SSL 以前由 Netscape 开发。两个协议在功能上不相上下。大多数实现同时支持这两个协议，以便与早期的纯 SSL 客户端向后兼容。

TLS 保护的通信可用于只实现机密性（加密），也可用于同时实现机密性和身份验证。X.509 证书可以是自行签名（也称为自行颁发），也可以由 X.509 CA 颁发。X.509 CA 是颁发证书的第三方公用证书颁发机构或组织中部署的公钥基础结构 (PKI)。除非另有说明，否则本主题将上述两种解决方案均称为证书颁发机构 (CA)。第三方公用 CA 称为公用 CA。

下面的 Exchange 2007 组件使用证书对会话进行加密或身份验证：

  • SMTP   使用证书进行加密和身份验证，以实现合作伙伴组织之间的域安全性。对集线器传输服务器与边缘传输服务器之间的直接信任连接使用证书。在集线器传输服务器之间使用证书来对 SMTP 会话进行加密。在 Exchange 2007 中，“直接信任”是一项身份验证功能，Active Directory 目录服务或 Active Directory 应用程序模式 (ADAM) 目录服务中存在证书，即证明证书有效。Active Directory 被视为受信任的存储机制。还会对组织之间的机会型 TLS 会话使用证书。有关详细信息，请参阅Exchange 2007 中的 TLS 功能以及相关术语。

  • EdgeSync 同步   在 Microsoft Exchange EdgeSync 服务将数据从 Active Directory 复制到边缘传输服务器上的 ADAM 实例之后，将使用 Exchange 2007 创建的自签名证书对边缘传输服务器上的 ADAM 实例与内部 Active Directory 服务器之间的 LDAP 通信进行加密。自签名证书是由其创建者签署的证书。Microsoft Exchange EdgeSync 服务是定期将配置数据从 Active Directory 复制到已订阅的边缘传输服务器的数据同步服务。有关详细信息，请参阅了解 EdgeSync 同步进程。

  • POP3 和 IMAP4   使用证书对邮局协议版本 3 (POP3) 和 Internet 消息访问协议版本 4rev1 (IMAP4) 客户端与 Exchange 服务器之间的会话进行身份验证和加密。有关详细信息，请参阅管理 POP3 和 IMAP4 服务。

  • 统一消息   使用证书对传入集线器传输服务器以及统一消息 (UM) IP 网关和 Microsoft Office Communications Server 2007 的 SMTP 会话进行加密。有关详细信息，请参阅了解统一消息 VoIP 安全性。

  • 自动发现   使用证书对客户端与客户端访问服务器之间的 HTTP 路径进行加密。有关详细信息，请参阅白皮书：Exchange 2007 Autodiscover Service。

  • 客户端访问应用程序   使用证书对客户端访问服务器与各种 HTTP 客户端（诸如 Outlook Anywhere、Microsoft Outlook Web Access 以及支持 Microsoft Exchange ActiveSync 的设备）之间的路径进行加密。有关详细信息，请参阅管理客户端访问安全性。

有关如何对 Exchange 2007 中的每个数据路径进行加密和身份验证的详细信息，请参阅数据路径安全性参考。

返回顶部

如何确定何时使用公用 CA 颁发的证书以及何时使用自签名证书

本部分将简要介绍 Exchange 2007 如何使用证书。阅读本部分内容之后，应根据已启用的 Exchange 组件以及要支持的客户端，了解需要从公用 CA 购买哪种证书。本部分稍后还将针对较为技术性的内容提供常用的上下文。

请注意，因为本部分旨在帮助您快速确定与公用 CA 有关的总体证书要求，所以内容必须非常简洁。为了简洁起见，提供了证书和相关技术的许多概括性内容，来说明证书在 Exchange 2007 中的使用。如果无法理解本部分提供的概念，请务必阅读本主题中的其他所有内容以及参考文档。

通常情况下，任何使用 Kerberos、直接信任或 NTLM 身份验证的 Exchange 2007 组件都可以使用自签名证书进行加密。在本主题中，此类组件称为内部 Exchange 2007 组件。“内部”是指数据路径在 Exchange 2007 服务器之间并且在 Active Directory 所定义的公司网络内。

建议只要您的用户从公司防火墙外部访问要求进行身份验证和加密的 Exchange 组件，您就应部署公用 CA 颁发的证书。例如，客户端访问服务器角色支持的所有不同客户端（诸如 Exchange ActiveSync、POP3、IMAP4 和 Outlook Anywhere）均应使用公用 CA 颁发的证书进行保护。在本主题中，此类组件称为外部 Exchange 2007 组件。“外部”是指客户端与 Exchange 2007 服务器之间的数据路径穿过公司防火墙并且延伸到 Internet。

内部组件使用自签名证书

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

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

note注意：
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 时需要公用 CA 颁发的证书

内部 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 的规范生成证书请求。

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

本部分的剩余内容将介绍这些相关信息：如何确定必须购买的公用证书类型，以及是否必须购买多个证书来帮助保护组织中用于访问 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

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

  • Internet Explorer (Outlook Web Access)

  • Exchange 边缘传输服务器（域安全性）

important要点：
如果证书中使用通配符名称，运行 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 的信誉。

返回顶部

了解证书属性以及 Exchange 2007 如何使用这些证书属性

了解证书的各种属性不仅有助于您了解 Exchange 如何使用证书，还有助于您规划 Exchange 组织中的证书需要以及解决多种问题。

X.509 证书包含两种属性。

  • 证书字段是 X.509 证书本身的签名数据中的属性。这些字段通过签名保护完整性，如果不重新签署或重新颁发证书，就无法更改它们的值。

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

    例如，您可以通过 Enable-ExchangeCertificate cmdlet 向创建的证书的属性中添加服务。可以启用证书供 IIS（例如 Outlook Web Access 或 Exchange ActiveSync）、SMTP（例如直接信任或域安全性）、IMAP、POP 和统一消息使用。对证书启用特定的服务可更新证书属性。有关详细信息，请参阅Enable-ExchangeCertificate。

可以通过对给定证书运行包含 |FL 参数的 Get-ExchangeCertificate cmdlet 来查看这些属性。如果运行的是 Exchange 2007 RTM，必须运行包含 |FL* 参数的 cmdlet 来显示所有属性数据。

Get-ExchangeCertificate cmdlet 输出中指定的某些字段和属性将映射到 X.509 扩展字段，您可以使用 Microsoft 管理控制台 (MMC) 中的证书管理器来查看这些扩展字段。有关证书管理器的详细信息，请参阅如何向 Microsoft 管理控制台添加证书管理器。有关 Get-ExchangeCertificate cmdlet 的详细信息，请参阅 Get-ExchangeCertificate。

证书字段

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

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

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

Issuer

该字段包含标识证书颁发者的公用名。Exchange 在安装期间创建的或通过 New-ExchangeCertificate cmdlet 创建的自签名证书会显示 cn=hostname，其中 hostname 是本地服务器的名称。

CA 颁发的证书通常在“Issuer”字段中显示 CA 的完整公用名。

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

Issuer 字段没有可以在 New-ExchangeCertificate cmdlet 中设置的相应参数。Issuer 字段由颁发证书的实体指定。

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 行为的详细信息。

note注意：
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）的证书。该域是可接受的域。但是应注意，某些旧版客户端和移动设备不支持证书中的通配符名称，因此，可能不支持使用通配符域。

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

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

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

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

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

NotBefore 和 NotAfter

NotBefore 和 NotAfter 字段中的值代表证书有效的日期范围。如果当前日期在 NotAfter 日期之后，证书将被视为过期。Microsoft Exchange 仍可以使用过期证书，但是客户端将生成警告，并且服务器将在事件日志中记录相应的事件。

映射到 NotBefore 值的 X.509 证书扩展名是 Valid from。映射到 NotAfter 的 X.509 证书扩展名是 Valid to。

NotBefore 和 NotAfter 字段没有可以在 New-ExchangeCertificate cmdlet 中设置的相应参数。这些字段由颁发证书的实体定义。通过 Exchange 安装程序或 New-ExchangeCertificate cmdlet 生成的自签名证书的有效期为一年。

CertificateRequest

只有仍处于申请状态的证书中会出现该值。证书请求不是有效的 X.509 证书，因此，Exchange 不会使用。

通过指定 New-ExchangeCertificate cmdlet 的 GenerateRequest 参数开关，可以启用 CertificateRequest 字段。

证书属性

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

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

本部分将介绍证书属性。

IsSelfSigned

IsSelfSigned 属性表示证书是否是自签名证书。自签名证书通常是根证书。该证书是证书链中没有任何其他证书的证书。Exchange 中的自签名证书通常是指下列类型的证书：

  • 在不存在任何合格证书的服务器上安装 Exchange 时生成的证书。

  • 通过运行 New-ExchangeCertificate cmdlet 生成的证书。

在安装集线器传输服务器角色、边缘传输服务器角色、统一消息服务器角色或客户端访问服务器角色时，通过 Exchange 安装程序生成一个自签名证书。如果主机计算机上的“个人”证书存储中存在有效的证书，将使用现有证书，不会使用 Exchange 安装程序生成的自签名证书。有效值为 True 或 False。

RootCAType

RootCAType 属性标识颁发证书的 CA 的类型。如果将 IsSelfSigned 参数设置为 True，RootCAType 属性的值应为 None。否则，证书可能会导致在证书选择过程中出现意外的结果。其他可能的值如下：

  • Registry   已手动安装在证书存储中的内部私有 PKI 根 CA。

  • ThirdParty   公用第三方根 CA。

  • GroupPolicy   已使用组策略部署的内部私有 PKI 根 CA。

  • Enterprise   已使用 Active Directory 部署的内部私有 PKI 根 CA。

  • Unknown   Exchange 无法确定所安装的证书类型。

了解根 CA 证书如何安装在计算机上可能会帮助您诊断不一致的信任策略。此类不一致现象可能会导致证书在某些服务器上有效，但是在其他服务器上无效。

例如，值为 Registry 表示某个用户已在一台服务器上手动安装了证书。如果尚未在组织中的其他服务器上安装该证书，这可能会导致不一致。建议使用组策略或 Active Directory 将证书分发到所有计算机。

Services

Services 属性标识可以使用该证书的服务。有效值为 SMTP、POP、IMAP、UM 和 IIS。

通过在 Enable-ExchangeCertificate cmdlet 中指定 Services 参数，可以设置 Services 字段中的值。有关详细信息，请参阅Enable-ExchangeCertificate。

Status

Status 属性标识证书是否有效。在解决证书问题时，Status 字段非常有帮助。如果给定证书的 Status 值不是 Valid，Exchange 服务器将不会对任何服务使用该证书。Status 属性的值包括：

  • Unknown   该状态通常表示无法验证证书的状态，因为证书吊销列表 (CRL) 不可用或此服务器无法连接到该证书吊销列表。确保计算机可以连接到证书吊销机构。有关详细信息，请参阅如何为 WinHTTP 配置代理设置。

  • Valid   证书工作正常。

  • Revoked   CRL 表示该证书已被吊销。必须生成新的证书。

  • DateInvalid   该状态表示系统时间不正确、证书已过期或签署文件的系统的时间不正确。验证是否符合下列条件：

    • 本地计算机时钟是准确的。

    • 证书尚未过期。

    • 发送系统时钟是准确的。

    如果证书已过期，则必须生成新证书。

  • Untrusted   该状态表示证书不是自签名证书。但是，已由本地计算机不信任的 CA 签署。必须将该 CA 证书添加到计算机上的受信任根证书颁发机构存储中。有关如何手动向本地证书存储添加证书的详细信息，请参阅 MMC 中证书管理器的帮助文件。

  • Invalid   某个其他问题已使该证书失效，例如证书路径的某个位置存在不受信任的、无效的或已吊销的证书。

有关疑难解答的详细信息，请参阅下列主题：

HasPrivateKey

HasPrivateKey 属性表示所安装的证书是否包含私钥。这一点非常重要，因为 Microsoft Exchange 传输服务、Microsoft Exchange POP3 服务和 Microsoft Exchange IMAP4 服务不会使用没有私钥的证书。

Thumbprint

Thumbprint 属性是用于标识证书的唯一字符串。如果在多个 Exchange 服务器上安装相同的证书，可以通过指纹标识证书。如果多个边缘传输服务器要接受具有相同 FQDN（例如 mail.fourthcoffee.com）的邮件，通常会在多个 Exchange 服务器上安装相同的证书。在多个服务器上安装相同的证书比为每个服务器申请新证书更加经济。但是，证书必须包含可导出的私钥。

Thumbprint 属性用于指定下列 cmdlet 的证书：

映射到 Thumbprint 属性的 X.509 证书扩展名也是 Thumbprint。

返回顶部

证书信任和验证

若要使用证书进行身份验证，必须验证并信任该证书。

若要验证给定的 X.509 证书，必须信任颁发证书的根 CA。根 CA 是最受信任的 CA。该 CA 在 CA 的顶部。根 CA 具有自签名证书。运行依赖于证书身份验证的应用程序时，每个证书的证书链必须在本地计算机的受信任根容器中的证书结束。受信任根容器包含根 CA 颁发的证书。

证书通过另一个证书链接到 CA。该证书也可能是由某个 CA 颁发的，因此会链接到该 CA。该证书链也称为“证书路径”。证书路径中的每个证书必须都有效，证书才能有效。此外，证书链顶部的证书必须是受信任的根 CA。

可以使用两种类型的受信任根 CA 实现依赖证书身份验证的应用程序：第三方公用根 CA 和私有根 CA。

第三方公用根证书颁发机构

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 的设备上安装根证书。

important要点：
可能无法在用户将用于访问 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。

配置 WinHTTP 的代理设置

Exchange 2007 服务器依赖基本的 Windows HTTP Services (WinHTTP) 管理所有 HTTP 和 HTTPS 通信。例如，集线器传输服务器和边缘传输服务器可以使用 HTTP 访问对 Exchange 2007 标准反垃圾邮件筛选器更新和 Microsoft Forefront Security for Exchange Server 反垃圾邮件更新服务的更新。所有 Exchange 服务器角色将使用 WinHTTP 启用 CRL 验证。

有关详细信息，请参阅如何为 WinHTTP 配置代理设置。

测试 PKI 和代理配置

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

返回顶部

创建、导入和启用证书

可以通过多种方式获取在 Exchange 2007 上安装并使用的证书。您可以根据自己的需要来选择要使用的方法。Exchange 2007 可生成一组自签名证书，以保护默认配置。应在特定时间续订证书以帮助确保系统的安全。Exchange 不会自动生成要证书颁发机构签署证书的请求。无论是希望创建新的自签名证书还是创建证书颁发机构的证书请求，两种方法都将使用相同的 cmdlet。

本部分概要介绍了可以对 Exchange 2007 所使用的证书执行的操作。如果对 ExchangeCertificate cmdlet 不是很了解，请阅读本部分的内容。特定的应用程序示例和步骤将在本文档后面的部分中提供，并以 POP3 为例。本部分还提供特定应用程序文档的链接。

证书 Cmdlet

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

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

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

生成自签名证书

若要生成自签名证书，以供主机名为 Server1、域为 fourthcoffee.com 的服务器的 SMTP 服务使用，请运行以下命令：

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

克隆自签名证书

如果现有的自签名证书需要续订，可以通过运行以下命令克隆该证书：

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

thumbprint 占位符是要续订的证书的指纹。还可以在以下命令中指定新证书的服务：

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 命令行管理程序将显示请求的指纹。

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

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

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

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

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

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

导入证书

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

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

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

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

启用证书

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

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

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

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

验证证书安装

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

Get- ExchangeCertificate <thumbprint> | fl *
note注意：
如果运行的是 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 *
note注意：
如果运行的是 Exchange 2007 SP1 或更高版本，不要在命令参数中包含星号 (*)。

IIS

启用 IIS 时，默认 IIS 网站将更新为使用该特定证书。

只能通过对默认 IIS 网站使用 Enable-ExchangeCertificate cmdlet，为证书启用 IIS。如果要驻留 Outlook Web Access 或自动发现的网站不是默认 IIS 网站，必须使用 IIS 管理器将特定证书与这些网站相关联。

SMTP

对证书启用 SMTP 服务时，将对网络服务帐户授予到 Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys 目录中的相应私钥文件的读取访问权限。该操作可提供 Microsoft Exchange 传输服务访问和使用私钥来解密 TLS 保护的邮件时所需的权限。

Microsoft Exchange 统一消息服务

对证书启用 Microsoft Exchange 统一消息服务时，证书属性将更新为包含统一消息。如果符合下列条件，将使用证书：

  • 统一消息服务器角色已安装在计算机上。

  • 证书的 CertificateDomains 证书字段中包含本地计算机的物理 FQDN。

返回顶部

证书选择

证书选择是 Exchange 组件为确定应用于传入连接的证书而执行的过程。SMTP STARTTLS、POP3 和 IMAP4 都需执行类似的选择过程来确定要用于特定会话的证书。该过程是非常明确的，但也可能会产生混淆，尤其在计算机上安装了多个证书时更是如此。

本部分将介绍 SMTP STARTTLS、SMTP X-AnonymousTLS、POP3 和 IMAP4 的证书选择过程。有关传输特定的证书选择的详细信息，请参阅 SMTP TLS 证书选择。

SMTP STARTTLS

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

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

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

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

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

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

  • Enhanced Key Usage 字段包含服务器身份验证对象标识符（也称为 OID）或为空。

  • PKI 证书扩展列出 RSA 密钥，至少为 1024 位。

  • 证书将验证证书链，直至受信任的根，或证书是自签名证书。

  • 证书和证书链通过吊销检查。

  • 私钥存在并且可用。

  • 私钥未存储在可移除设备中。

  • 私钥未使用密码进行保护。

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

  • NotBefore 字段中的值   Exchange 选择最新的有效证书。

  • 受信任的 CA 颁发的证书与自签名证书   与自签名证书相比，Exchange 优先选择受信任的 CA 颁发的证书。

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

SMTP X-AnonymousTLS

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

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

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

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

POP3 和 IMAP4

与 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 的过程相同。

note注意：
在 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. 过期期限最短的自签名证书。

返回顶部

详细信息

本主题中引用了下列文档：

返回顶部