通过

了解数字证书和 SSL

  • 项目

**适用于：**Exchange Server 2010

**上一次修改主题：**2009-12-01

安全套接字层 (SSL) 是确保客户端与服务器之间通信安全的一种方法。对于 Microsoft Exchange Server 2010 客户端访问服务器，SSL 用于帮助保护服务器和客户端之间的通信。客户端包括移动设备、组织网络内部的计算机以及组织网络外部的计算机。它们包括具有或不具有虚拟专用网 (VPN) 连接的客户端。

默认情况下，在安装 Exchange 2010 时，如果使用 Microsoft Office、Outlook Web App Exchange ActiveSync 和 Outlook Anywhere，将使用 SSL 对客户端通信进行加密。默认情况下，邮局协议版本 3 (POP3) 和 Internet 邮件访问协议版本 4 rev1 (IMAP4) 未配置为通过 SSL 进行通信。

SSL 要求使用数字证书。本主题概述了不同类型的数字证书，以及有关如何将客户端访问服务器配置为使用这些类型数字证书的信息。

目录

数字证书概述

数字证书和代理

数字证书最佳做法

客户端限制

数字证书概述

数字证书是一种电子文件，其作用如同在线密码一样，可验证用户或计算机的身份。使用它们可以创建用于客户端通信的 SSL 加密通道。证书是由证书颁发机构 (CA) 颁发的数字声明，由 CA 证明证书持有者的身份并使参与各方能通过加密以安全方式进行通信。

数字证书的作用如下：

  • 它们验证其持有者（人员、网站，甚至是路由器之类的网络资源）确实与自己所声称的身份相符。
  • 它们保护联机交换的数据不被偷窃或篡改。

数字证书可由受信任的第三方 CA 或 Microsoft Windows 公钥基础结构 (PKI) 通过使用证书服务颁发，也可以通过自行签署产生。每种类型的证书都有优点和缺点。每种类型的数字证书都是防篡改的，并且无法伪造。

可针对多种功能颁发证书。这些功能包括 Web 用户身份验证、Web 服务器身份验证、安全/多用途 Internet 邮件扩展 (S/MIME)、Internet 协议安全 (IPsec)、传输层安全性 (TLS) 和代码签名。

证书包含一个公钥并且将此公钥与持有相应私钥的个人、计算机或服务的身份连接在一起。客户端和服务器使用这些公钥和私钥在传输数据前对其进行加密。对于基于 Windows 的用户、计算机和服务，如果受信任根证书存储中存在根证书副本并且该证书包含有效的证书路径，那么它们就建立了对该 CA 的信任。未被吊销并且未超过有效期的证书才是有效的证书。

证书类型

数字证书有三个主要类型：自签名证书、Windows PKI 生成的证书以及第三方证书。

自行签署证书

安装 Exchange 2010 时，会自动配置自签名证书。自签名证书由创建它的应用程序签署。证书的主题和名称是一致的。颁发者和主题在证书上定义。自签名证书允许一些客户端协议使用 SSL 进行通信。Exchange ActiveSync 和 Outlook Web App 可使用自签名证书建立 SSL 连接。Outlook Anywhere 不能与自签名证书一起使用。自签名证书必须手动复制到客户端计算机或移动设备的受信任根证书存储中。如果客户端通过 SSL 连接到服务器，并且该服务器包含自签名证书，系统将提示客户端验证该证书是否由受信任的颁发机构颁发。客户端必须明确信任颁发证书的颁发机构。如果客户端确认信任，SSL 通信可继续。

通常，小型组织会决定不使用第三方证书或不安装自己的 PKI 来颁发自己的证书。由于这些解决方案费用昂贵，或者由于管理员经验不足或缺乏创建自己的证书层次结构方面的知识，亦或前述两种原因都有，所以他们可能会做出这种决定。如果使用自签名证书，则成本低且安装简单。但是，如果使用自签署证书，为证书生命周期管理、续订、信任管理和吊销建立基础结构要更加困难。

Windows 公钥基础结构证书

证书的第二种类型是 Windows PKI 生成的证书。PKI 是由数字证书、证书颁发机构和注册颁发机构 (RA) 组成的系统，该系统可以通过使用公钥加密来验证和辨认电子交易中涉及的各方的有效性。在使用 Active Directory 的组织中实现 PKI 时，需要为证书生命周期管理、续订、信任管理和吊销提供基础结构。但是，部署服务器和基础结构从而创建和管理 Windows PKI 生成的证书会产生额外开销。

部署 Windows PKI 需要使用证书服务，可通过“控制面板”上的“添加或删除程序”进行安装。可以将证书服务安装在域中的任何服务器上。

如果从加入域的 Windows CA 获得证书，则可以使用该 CA 请求或签署证书，以便颁发给网络中您自己的服务器或计算机。这使您能够使用与第三方证书供应商相似的 PKI，但成本较低。尽管无法像其他类型的证书那样公开部署这些 PKI 证书，但是，当 PKI CA 使用私钥签署请求者的证书时，将对该请求者进行验证。此 CA 的公钥是该证书的一部分。将此证书放入受信任根证书存储中的服务器可使用该公钥解密请求者证书，并验证请求者的身份。

部署 PKI 生成的证书的步骤与部署自签名证书所需的步骤相似。还必须将从 PKI 得到的受信任根证书的副本安装到计算机或移动设备的信任根证书存储中，以便能够从这些计算机或移动设备建立到 Microsoft Exchange 的 SSL 连接。

通过 Windows PKI，组织可发布自己的证书。客户端可通过内部网络从 Windows PKI 请求或接收证书。Windows PKI 可续订或吊销证书。

受信任的第三方证书

第三方证书或商业证书是由第三方或商业 CA 生成然后由使用者购买以便在网络服务器上使用的证书。自签名证书和基于 PKI 的证书存在一个问题：因为客户端服务器或移动设备不会自动信任证书，因此必须确保将证书导入到客户端计算机和设备上的受信任根证书存储中。第三方证书或商业证书没有此问题。大多数商业 CA 证书都已获得信任，因为其证书已驻留在受信任的根证书存储中。由于颁发者受到信任，因此证书也受到信任。使用第三方证书可以极大地简化部署。

对于较大型的组织或必须公开部署证书的组织来说，即使使用第三方证书或商业证书会需要开销，使用这两种类型的证书仍然是最佳解决方案。对于中小型组织，商业证书可能不是最佳解决方案，您可能决定选择使用其他可用的证书。

选择证书类型

选择要安装的证书类型时，应考虑几个方面。证书必须签署才能有效。可以自签名或由 CA 签署。自签名证书有限制。例如，并非所有移动设备都允许用户在受信任根证书存储中安装数字证书。是否能在移动设备上安装证书取决于移动设备生产商和移动服务提供商。一些生产商和移动服务提供商禁止对受信任根证书存储的访问。在这种情况下，无论是自签名证书，还是来自 Windows PKI CA 的证书都不能在移动设备上安装。

大部分移动设备预安装了多个受信任第三方商业证书。为了获取最佳用户体验，通过使用运行 Windows Mobile 6.0 或更高版本的设备和使用由受信任第三方 CA 颁发的数字证书，实现对 Exchange ActiveSync 的基于证书的身份验证。

默认 Exchange 证书

默认情况下，Exchange 会安装默认的自签名证书，以便对所有网络通信进行加密。加密所有网络通信要求每台 Exchange 服务器都有一个其可以使用的 X.509 证书。您应该用客户端自动信任的证书替换此自签名证书。

“自签名”表示仅由 Exchange 服务器本身创建和签署证书。由于该证书不是由通常受信任的 CA 所创建和签署的，所以除了同一组织中的其他 Exchange 服务器外，任何软件都不会信任默认自签名证书。将为所有 Exchange 服务启用默认证书。默认证书具有主题备用名称 (SAN)，对应于安装了该证书的 Exchange 服务器的服务器名称。默认证书还具有 SAN 列表，其中包括该服务器的服务器名称和完全限定的域名 (FQDN)。

尽管 Exchange 组织中的其他 Exchange 服务器会自动信任此证书，但是客户端（如 Web 浏览器、Outlook 客户端、移动电话以及除外部电子邮件服务器之外的其他电子邮件客户端）都不会自动信任它。因此，请考虑在已安装客户端访问服务器角色的 Exchange 服务器和任何面向外部的集线器传输服务器上用受信任的第三方证书替换此证书。如果您拥有自己的内部 PKI，并且所有客户端都信任该实体，您也可以使用自己颁发的证书。

服务的证书要求

证书在 Exchange 中有多种用途。大多数客户还可以在多个 Exchange 服务器上使用证书。通常，您拥有的证书越少，证书管理就变得越容易。

IIS

下列所有 Exchange 服务在给定 Exchange 服务器上都使用相同的证书：

  • Outlook Web App
  • Exchange 控制面板
  • Exchange Web 服务
  • Exchange ActiveSync
  • Outlook Anywhere
  • 自动发现
  • Outlook 通讯簿分发

因为只有一个证书可以与网站关联，并且由于所有这些服务默认情况下都是在一个网站上提供，所以这些服务的客户端使用的所有名称必须在证书中（或在证书中的通配符名称下）。

POP/IMAP

用于 POP 或 IMAP 的证书可以从用于 IIS 的证书中单独指定。但是，为了简化管理，我们建议您在 IIS 证书中包括 POP 或 IMAP 服务名称，并为所有这些服务使用一个证书。

SMTP

可以为在集线器传输服务器或边缘传输服务器上配置的每个接收连接器使用单独的证书。证书必须包括 SMTP 客户端（或其他 SMTP 服务器）使用的名称才能到达该连接器。要简化证书管理，请考虑在单个证书中包括您要支持 TLS 通信的所有名称。

实时联合

用于与 Windows Live 联合以实现 Exchange 共享方案的证书可以包括任何名称。在联合过程中，请标识希望 Exchange 服务器使用的证书。此证书必须由 Windows Live 信任的第三方证书颁发机构颁发。如果从 Windows Live 信任的第三方证书颁发机构获得其他服务的 Exchange 证书，您可以使用这些服务的单一证书，也可以与 Windows Live 联合。

统一消息

将 Exchange 统一消息服务器连接到 Microsoft Office Communications Server 2007 服务器或第三方 SIP 网关或专用交换机 (PBX) 电话设备时，必须使用与统一消息服务器的 FQDN 匹配的证书。可以通过下列方法实现此目的：使用与所有统一消息服务器匹配的通配符证书；在证书 SAN 列表中包括统一消息服务器的 FQDN；或使每个其 FQDN 位于证书的 SAN 中的统一消息服务器具有单独的证书。推荐的方法是在证书 SAN 列表中包括统一消息服务器 FQDN。

Outlook Web App 即时消息与 Office Communications Server 2007 R2

Exchange 2010 中的 Outlook Web App 包括一个编程接口，允许即时消息提供程序将加载项写入控制存在和即时消息功能。存在 Communications Server 2007 R2 的加载项。使用此加载项时，必须使用证书保护 Communications Server 2007 R2 服务器和 Exchange 2010 客户端访问服务器之间的连接。该证书必须安装在 Exchange 客户端访问服务器上。

旧版 Exchange Server

如果遵循从 Microsoft Exchange Server 2003 或 Exchange Server 2007 转换到 Exchange 2010 的最佳做法，当您在 Exchange 的旧版本和 Exchange 2010 上拥有邮箱时，会引入一个新主机名 legacy.contoso.com，以在共存期间使用。此旧版主机名也应该包括在您使用的证书中。有关如何从 Exchange Server 2003 和 Exchange 2007 升级到 Exchange 2010 的详细信息，请参阅从 Exchange 2003 客户端访问升级和从 Exchange 2007 客户端访问升级。

数字证书和代理

代理是一种方法，通过此方法，客户端访问服务器可以将客户端连接发送到另一个客户端访问服务器。有两种情况一个客户端访问服务器会将通信代理到另一个客户端访问服务器。

  1. 面向 Internet 的 Active Directory 站点中的客户端访问服务器会将通信代理到非面向 Internet 的站点中的客户端访问服务器。这可以确保客户端请求的所有处理会尽可能接近客户端的邮箱服务器进行处理。
  2. Exchange 2010 的客户端访问服务器会代理在 Exchange 2003 或 Exchange 2007 上拥有邮箱的客户端的连接。这些客户端连接将通过代理连接到 Exchange 2007 客户端访问服务器。发生这种情况是因为，对于许多 Exchange 服务，客户端访问服务器无法处理运行较旧版本的 Exchange 的邮箱服务器的请求。

客户端访问服务器代理请求时，SSL 用于加密而不是进行身份验证。在大多数情况下，自签名证书可用于客户端访问服务器代理。如果组织要求特别的安全规则，您可以设置配置密钥来要求受信任的证书实现客户端访问服务器代理。在此方案中，您可以通过将以下密钥设置为 false 来进行配置：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts

不正确地编辑注册表时，可能导致出现严重问题，从而需要重新安装操作系统。因不正确地编辑注册表而导致出现的问题是能够解决的问题。在编辑注册表之前，请备份任何有用数据。

有关代理的详细信息，请参阅Understanding Proxying and Redirection。

反向代理和证书

大多数 Exchange 部署使用反向代理在 Internet 上发布 Exchange 服务。常见的反向代理产品的示例是 Microsoft Internet Security and Acceleration (ISA) Server 和检查点。可以对这些反向代理进行配置以终止 SSL 加密、检查服务器上明文形式的通信，然后打开从反向代理服务器到其后面的 Exchange 服务器的新 SSL 加密通道。这称为 SSL 桥接。配置反向代理服务器的另一种方法是使 SSL 连接直接通过反向代理服务器后的 Exchange 服务器。借助任何一种部署模型，Internet 上的客户端会使用 Exchange 访问的主机名（如 mail.contoso.com）连接到反向代理服务器。然后，反向代理服务器使用不同的主机名（如 Exchange 客户端访问服务器的计算机名）连接到 Exchange。您不必在证书上包括 Exchange 客户端访问服务器的计算机名，因为大多数常见的反向代理服务器都能够将客户端使用的原始主机名与 Exchange 客户端访问服务器的内部主机名匹配。

负载平衡和证书

如果有多个客户端访问服务器，请考虑配置一个客户端访问服务器数组。此数组将允许所有客户端通过单一主机名连接到 Exchange 客户端访问服务器。只要所有客户端访问服务器都位于同一 Active Directory 站点内，您就可以将任意所需数目的客户端访问服务器计算机添加到一个客户端访问服务器数组。有关负载平衡和客户端访问服务器数组的详细信息，请参阅Understanding Proxying and Redirection和管理客户端访问服务器。

SSL 和拆分 DNS

拆分 DNS 是一种允许您为同一主机名配置不同 IP 地址的技术，具体取决于 DNS 请求的来源。这也称为水平分割 DNS、拆分视图 DNS 或网络分区 DNS。拆分 DNS 可以帮助您减少必须为 Exchange 管理的主机名的数量，方法是允许客户端通过同一主机名连接到 Exchange，而无论客户端是从 Internet 还是 Intranet 进行连接的。拆分 DNS 允许来自 Intranet 的请求而不是来自 Internet 的请求接收不同的 IP 地址。

拆分 DNS 在小型 Exchange 部署中通常是不必要的，因为用户可以访问同一 DNS 终结点，无论其通过 Intranet 还是 Internet 连接的。但是，对于较大的部署，此配置会导致传出 Internet 代理服务器和反向代理服务器上的负载过高。对于较大的部署，请配置拆分 DNS，以便外部用户访问 mail.contoso.com，内部用户访问 internal.contoso.com。将拆分 DNS 用于此配置可确保用户不必根据所在位置牢记使用不同的主机名。

远程 PowerShell

Kerberos 身份验证和 Kerberos 加密用于远程 PowerShell 访问，两者均可通过 Exchange 管理控制台和 Exchange 命令行管理程序实现。因此，您不必配置 SSL 证书与远程 PowerShell 一起使用。

数字证书最佳做法

尽管组织的数字证书的配置会因其特定需要而有所不同，但包含有关最佳做法的信息可以帮助您选择适合您的数字证书配置。

Best Practice:使用受信任的第三方证书

要阻止客户端接收有关不受信任的证书的错误，Exchange 服务器使用的证书必须由客户端信任的人员颁发。尽管可以将大多数客户端配置为信任任何证书或证书颁发者，但更简单的方法是在 Exchange 服务器上使用受信任的第三方证书。这是因为大多数客户端已信任其根证书。有几个第三方证书颁发者可以提供专门针对 Exchange 配置的证书。您可以使用 Exchange 管理控制台生成适用于大多数证书颁发者的证书请求。

如何选择证书颁发机构

证书颁发机构是颁发证书并确保证书有效性的公司。客户端软件（例如，Microsoft Internet Explorer 等浏览器，或者 Windows 或 Mac OS 等操作系统）包含其信任的 CA 内置列表。此列表通常可以配置以添加和删除 CA，但是配置通常是一件很麻烦的事。当您选择要购买其证书的 CA 时，请使用以下条件：

  • 确保要连接到 Exchange 服务器的客户端软件（操作系统、浏览器和移动电话）信任该 CA。
  • 选择一个说明支持用于 Exchange 服务器的“统一通信证书”的 CA。
  • 确保该 CA 支持您将使用的各种类型的证书。考虑使用主题备用名称 (SAN) 证书。并不是所有 CA 都支持 SAN 证书，并且一些 CA 不支持您可能需要的数目的主机名。
  • 确保为证书购买的许可证允许您将该证书放在计划使用的任意数目的服务器上。一些 CA 只允许您将一个证书放在一台服务器上。
  • 比较 CA 之间的证书价格。

Best Practice:使用 SAN 证书

根据您在 Exchange 部署中配置服务名称的方式，您的 Exchange 服务器可能需要一个可以代表多个域名的证书。尽管通配符证书（例如 *.contoso.com 就是其中一个）可以解决此问题，但许多客户不愿意保留可用于任何子域的证书存在安全隐患。一种更安全的替代方法是在证书中将所需的每个域作为 SAN 列出。默认情况下，证书请求由 Exchange 生成时，会使用该方法。

Best Practice:使用 Exchange 证书向导请求证书

Exchange 中有许多使用证书的服务。请求证书时一个常见的错误是请求没有包括一组正确的服务名称。Exchange 管理控制台中的证书请求向导将帮助您在证书请求中包括正确的名称列表。该向导可以指定证书要处理的服务，并根据所选的服务，包括必须在证书中包含的名称，以便它可以与这些服务一起使用。当部署初始 Exchange 2010 服务器集并确定哪些主机名用于部署的不同服务后，运行证书向导。理想情况下，您只需在部署 Exchange 的每个 Active Directory 站点中运行一次证书向导。

不必担心忘记购买的证书 SAN 列表中的主机名，您可以利用免费提供宽限期的证书颁发机构，在宽限期内，您可以返回证书并请求使用几个其他主机名的相同的新证书。

Best Practice:尽可能少使用主机名

除了尽可能少使用证书外，您还应该尽可能少使用主机名。这种做法可以节省资金。许多证书提供商根据您添加到证书的主机名数收取费用。

您可以用来减少必须包括的主机名数，进而降低证书管理复杂性而采取的最重要步骤是，不要在证书的主题备用名称中包括各个服务器主机名。

必须在 Exchange 证书中包括的主机名是客户端应用程序用于连接到 Exchange 的主机名。以下是一个典型的主机名列表，Contoso 公司需要这些主机名：

  • Mail.contoso.com   此主机名涵盖与 Exchange 的大部分连接，包括 Microsoft Office Outlook、Outlook Web App、Outlook Anywhere、脱机通讯簿、Exchange Web 服务、POP3、IMAP4、SMTP、Exchange 控制面板和 ActiveSync。
  • Autodiscover.contoso.com   此主机名由支持自动发现的客户端使用，其中包括 Microsoft Office Outlook 2007 和更高版本、Exchange ActiveSync 和 Exchange Web 服务客户端。
  • Legacy.contoso.com   此主机名在与 Exchange Server 2003 或 Exchange 2007 的共存时是必需的。如果您的客户端其邮箱位于 Exchange 的旧版本和 Exchange 2010 上，则配置旧版主机名可避免用户在升级过程中必须了解第二个 URL。有关升级和共存的详细信息，请参阅从 Exchange 2003 客户端访问升级和从 Exchange 2007 客户端访问升级。

客户端限制

有几个 Exchange 客户端限制它们支持的证书。这些客户端及其限制总结如下：

  • Windows XP 或早期操作系统上的 Outlook   用于 Outlook Anywhere 的 Windows RPC over HTTP 组件要求 SAN 或证书的公用名必须与为 Outlook Anywhere 配置的证书主体名称相匹配。Outlook 2007 和更高版本使用自动发现来获得此证书主体名称。要在 Exchange 2010 客户端访问服务器上配置此值，请使用 Set-OutlookProvider 命令和 -CertPrincipalName 参数。将此参数设置为 Outlook 客户端用于连接到 Outlook Anywhere 的外部主机名。
  • 早于 Outlook 2010 的 Outlook 版本不支持用于 POP3 和 IMAP4 访问的 SAN 证书   Outlook 2007 Service Pack 2 中可用于 SAN 支持的修补程序。该修补程序位于此处（英文）。
  • 移动设备   一些移动设备（包括运行 Windows Mobile 5.0 的设备和一些 Palm 设备）不支持通配符证书。