通过

数字证书和 SSL

  • 项目

适用于：Exchange Server 2013

安全套接字层 (SSL) 是一种保护客户端和服务器之间的通信的方法。 对于 Exchange Server 2013，SSL 用于帮助保护服务器和客户端之间的通信。 客户端包括移动电话、组织网络内的计算机以及组织网络外部的计算机。

默认情况下，安装 Exchange 2013 时，使用 Outlook Web App、Exchange ActiveSync 和 Outlook Anywhere 时，将使用 SSL 加密客户端通信。

SSL 要求使用数字证书。 本主题总结了不同类型的数字证书，以及如何配置 Exchange 2013 以使用这些类型的数字证书。

数字证书概述

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

数字证书的作用如下：

  • 他们验证其持有者 (人员、网站，甚至网络资源（例如路由器) ）是否是他们声称的身份。

  • 它们保护在线交换的数据免受盗窃或篡改。

数字证书可由受信任的第三方 CA 或 Windows 公钥基础结构颁发， (PKI) 使用证书服务颁发，也可以自签名。 每种类型的证书都有优点和缺点。 每种类型的数字证书都是防篡改的，不能伪造。

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

证书包含一个公钥，并将此公钥与持有相应私钥的个人、计算机或服务的身份联系起来。 客户端和服务器在传输数据之前使用公钥和私钥对数据进行加密。 对于基于 Windows 的用户、计算机和服务，如果受信任的根证书存储中存在根证书的副本，并且证书包含有效的证书路径，则会建立对 CA 的信任。 要使证书有效，证书不得吊销，并且有效期不得过期。

证书类型

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

自签名证书

安装 Exchange 2013 时，会在邮箱服务器上自动配置自签名证书。 自签名证书由创建它的应用程序签名。 使用者和证书名称匹配。 颁发者和使用者在证书上定义。 此自签名证书用于加密客户端访问服务器和邮箱服务器之间的通信。 客户端访问服务器自动信任邮箱服务器上的自签名证书，因此邮箱服务器上不需要第三方证书。 安装 Exchange 2013 时，还会在客户端访问服务器上创建自签名证书。 此自签名证书将允许某些客户端协议使用 SSL 进行通信。 Exchange ActiveSync和Outlook Web App可以使用自签名证书建立 SSL 连接。 Outlook Anywhere 不适用于客户端访问服务器上的自签名证书。 必须手动将自签名证书复制到客户端计算机或移动设备上的受信任的根证书存储。 当客户端通过 SSL 连接到服务器并且服务器提供自签名证书时，系统会提示客户端验证证书是否由受信任的颁发机构颁发。 客户端必须显式信任颁发机构。 如果客户端确认信任，则 SSL 通信可以继续。

注意

默认情况下，在邮箱服务器上安装的数字证书是自签名证书。 无需将组织中的邮箱服务器上的自签名证书替换为受信任的第三方证书。 客户端访问服务器自动信任邮箱服务器上的自签名证书，邮箱服务器上的证书不需要其他配置。

通常，小型组织决定不使用第三方证书或不安装自己的 PKI 来颁发自己的证书。 他们做出此决定可能是因为这些解决方案过于昂贵，因为管理员缺乏创建自己的证书层次结构的经验和知识，或者出于这两个原因。 成本最低，使用自签名证书时设置简单。 但是，在使用自签名证书时，为证书生命周期管理、续订、信任管理和吊销建立基础结构要困难得多。

Windows 公钥基础结构证书

第二种类型的证书是 Windows PKI 生成的证书。 PKI 是由数字证书、证书颁发机构和注册机构 (RU) ，这些机构使用公钥加密来验证和验证电子事务中涉及的每一方的有效性。 在使用 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 的证书。

默认 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 管理中心 (EAC)

  • Exchange Web 服务

  • Exchange ActiveSync

  • Outlook Anywhere

  • 自动发现

  • Outlook 通讯簿分发

由于只有一个证书可以与网站关联，并且所有这些服务默认在单个网站下提供，因此这些服务的客户端使用的所有名称都必须在证书 (或属于证书) 中的通配符名称。

POP/IMAP

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

SMTP

可以针对配置的每个接收连接器使用单独的证书。 证书必须包含 SMTP 客户端 (或其他 SMTP 服务器) 用于访问该连接器的名称。 若要简化证书管理，请考虑在单个证书中包含必须支持 TLS 流量的所有名称。

数字证书和代理

代理是一个服务器将客户端连接发送到另一个服务器的方法。 对于 Exchange 2013，当客户端访问服务器将传入客户端请求代理到包含客户端邮箱的活动副本的邮箱服务器时，就会发生这种情况。

客户端访问服务器代理请求时，SSL 用于加密，但不用于身份验证。 邮箱服务器上的自签名证书对客户端访问服务器和邮箱服务器之间的流量进行加密。

反向代理和证书

许多 Exchange 部署使用反向代理在 Internet 上发布 Exchange 服务。 可以将反向代理配置为终止 SSL 加密，检查服务器上的明文中的流量，然后打开从反向代理服务器到其后面的 Exchange 服务器的新 SSL 加密通道。 这称为 SSL 桥接。 配置反向代理服务器的另一种方法是让 SSL 连接直接传递到反向代理服务器后面的 Exchange 服务器。 使用任一部署模型时，Internet 上的客户端使用用于 Exchange 访问的主机名（例如 mail.contoso.com）连接到反向代理服务器。 然后，反向代理服务器使用其他主机名（例如 Exchange 客户端访问服务器的计算机名称）连接到 Exchange。 无需在证书中包含 Exchange 客户端访问服务器的计算机名称，因为最常见的反向代理服务器能够将客户端使用的原始主机名与 Exchange 客户端访问服务器的内部主机名相匹配。

SSL 和拆分 DNS

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

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

远程 Windows PowerShell

Kerberos 身份验证和 Kerberos 加密用于从 Exchange 管理中心 (EAC) 和 Exchange 命令行管理程序进行远程Windows PowerShell访问。 因此，无需配置 SSL 证书以用于远程Windows PowerShell。

数字证书最佳做法

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

最佳做法：使用受信任的第三方证书

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

如何选择证书颁发机构

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

  • 确保将连接到 Exchange 服务器的客户端软件 (操作系统、浏览器和移动电话) 信任 CA。

  • 选择一个 CA，指出它支持“统一通信证书”以用于 Exchange 服务器。

  • 确保 CA 支持要使用的证书类型。 请考虑使用使用者可选名称 (SAN) 证书。 并非所有 CA 都支持 SAN 证书，其他 CA 不支持所需的主机名数。

  • 确保为证书购买的许可证允许将证书放在要使用的服务器数上。 某些 CA 仅允许将证书放在一台服务器上。

  • 比较 CA 之间的证书价格。

最佳做法：使用 SAN 证书

根据 Exchange 部署中的服务名称配置方式，Exchange 服务器可能需要一个可以表示多个域名的证书。 尽管通配符证书（例如*.contoso.com 的通配符证书）可以解决此问题，但许多客户对维护可用于任何子域的证书的安全影响感到不自在。 一种更安全的替代方法是将证书中的每个必需域列为 SAN。 默认情况下，当 Exchange 生成证书请求时，将使用此方法。

最佳做法：使用 Exchange 证书向导请求证书

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

无需担心忘记你购买的证书的 SAN 列表中的主机名，可以使用一个证书颁发机构，该证书颁发机构免费提供一个宽限期，在此期间，你可以返回证书并请求包含几个附加主机名的相同新证书。

最佳做法：尽可能少地使用主机名

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

若要减少必须具有的主机名数，因此，证书管理的复杂性，可以采取的最重要步骤是不在证书的使用者可选名称中包含单独的服务器主机名。

必须在 Exchange 证书中包含的主机名是客户端应用程序用于连接到 Exchange 的主机名。 下面是名为 Contoso 的公司需要的典型主机名的列表：

  • Mail.contoso.com：此主机名涵盖与 Exchange 的大多数连接，包括 Microsoft Outlook、Outlook Web App、Outlook Anywhere、脱机通讯簿、Exchange Web 服务、POP3、IMAP4、SMTP、Exchange 控制面板和 ActiveSync。

  • Autodiscover.contoso.com：此主机名由支持自动发现的客户端使用，包括 Microsoft Office Outlook 2007 及更高版本、Exchange ActiveSync和 Exchange Web Services 客户端。

  • Legacy.contoso.com：在 Exchange 2007 和 Exchange 2013 共存方案中，需要此主机名。 如果客户端在 Exchange 2007 和 Exchange 2013 上具有邮箱，则配置旧主机名可防止用户在升级过程中学习第二个 URL。

了解通配符证书

通配符证书旨在支持域和多个子域。 例如，为 *.contoso.com 配置通配符证书会产生适用于 mail.contoso.com、web.contoso.com 和 autodiscover.contoso.com 的证书。