Outlook 安全警报 - 安全证书上的名称无效或与站点名称不匹配

Question

运行 Exchange 2007 和 IIS6.0 的 SBS 2008

A公司还有另外两家在同一屋檐下运营的公司。为了容纳电子邮件，我们为每位用户设置了 3 个 Exchange 帐户来进行管理。所有用户都使用他们的 CompanyA 帐户登录域。

• CORP\user user@companyA.com
• CORP\user-companyb user@companyB.com <-- 仅用于电子邮件
• CORP\user-companyc user@companyC.com <-- 仅用于电子邮件

电子邮件在内部和通过 OWA 工作正常。为需要访问companyB和companyC邮件的远程用户设置Outlook时存在问题，Outlook弹出证书错误。

SSL 证书 SAN 具有以下 DNS 名称：

• webmail.companyA.com
• www.webmail.companyA.com
• 公司-SBS
• CORP-SBS.local
• autdiscover.companyA.com

远程访问 companyC 电子邮件地址的用户告诉我，以前从未发生过这种情况。这始于 CEO 自己更改了 DNS 提供商，在此过程中原始 DNS 设置丢失了。他提到了有关正在创建的 SRV 记录的一些内容，该记录纠正了这个问题，但仅此而已。

寻求有关如何正确解决此问题的指导。

Answer 1

此问题很可能是由 Outlook 的自动发现服务（Outlook Anywhere功能的一部分）引起的。自动发现向最终用户的 Outlook 客户端提供有关 Exchange 提供的各种服务及其所在位置的各种信息；这用于多种目的：

• 首次运行 Outlook 时自动配置 Outlook 配置文件，可以仅使用用户的电子邮件地址和密码配置 Exchange 帐户，因为其他信息会自动定位和检索。

• Outlook 客户端访问的基于 Web 的服务的动态位置，包括外出助理、统一消息功能、Exchange 控制面板 (ECP) 的位置等。

这是 Microsoft 对RFC 6186的专有实现。不幸的是，他们并没有真正遵循 Outlook Anywhere 设计中该 RFC 的建议，但这也许是可以预料的，因为 Exchange 和 RPC over HTTPS 功能不是传统的 IMAP/SMTP 服务器。

自动发现如何工作（对于外部*用户）？

自动发现与客户端访问服务器上的 Web 服务通信（在这种情况下，所有角色都在 SBS 服务器上）位于路径/Autodiscover/Autodiscover.xml，根除其默认网站。为了找到要与之通信的服务器的 FQDN，它会删除电子邮件地址的用户部分，留下域（即 @companyB.com）。它依次尝试使用以下每个 URL 与 Autodiscover 通信：

• https://companyB.com/Autodiscover/Autodiscover.xml
• https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

如果这些失败，它将通过禁用 SSL 并尝试在端口 80 (HTTP) 上进行通信来尝试非安全连接，通常是在提示用户确认这是一个可接受的操作之后（我认为这是一个有缺陷的选项，因为无知的用户会通常批准这一点，并冒着通过纯文本发送凭据的风险——不需要凭据和业务敏感数据的安全通信的无知系统管理员对业务连续性构成风险）。

最后，使用 DNS 中的服务记录 (SRV) 进行后续检查，该服务记录位于companyB.com命名空间之外的知名位置，可以将 Outlook 重定向到服务器正在侦听的正确 URL。

会出什么问题？

在此过程中可能会出现以下几个问题之一：

没有 DNS 条目

通常，域的根 ( companyB.com) 可能无法解析为 DNS 中的主机记录。不正确的 DNS 配置（或有意决定不公开 Outlook Anywhere 服务）可能意味着该autodiscover.companyB.com记录也不存在。

在这些情况下，没有什么大问题；Outlook 只是继续使用最后一个已知配置与 Exchange 通信，并且可能会在某些基于 Web 的功能方面降级，因为它需要通过自动发现检索 URL（例如外出助理）。解决方法是使用 Outlook Web Access 访问此类功能。

新 Outlook 配置文件中 Exchange 帐户的自动配置也不是自动的，需要手动配置 RPC over HTTPS 设置。但是，这不会导致您描述的问题。

错误的 SSL 证书

Outlook 用来尝试联系 Exchange Server 的 URL 完全有可能解析为主机，该主机可能是也可能不是客户端访问服务器。如果 Outlook 可以在端口 443 上与该服务器通信，则当然会交换证书以在 Outlook 和远程服务器之间建立安全通道。如果 Outlook 认为与之通信的 URL 未列在该证书上——无论是作为通用名称还是主题备用名称 (SAN)——这将导致 Outlook 显示您在初始帖子中描述的对话框。

发生这种情况的原因有多种，全部取决于 DNS 的配置方式以及 Outlook 如何检查我上面描述的 URL：

• 如果https://companyB.com/... URL 解析为主机记录，并且该地址的 Web 服务器在端口 443 上侦听，并且它的 SSL 证书未companyB.com在公用名称或主题备用名称中列出，则将出现问题。主机是否是 Exchange Server 无关紧要；它可能是托管未正确配置的公司网站的 Web 服务器。Corrige：

  • 禁用companyB.com区域根部的主机记录（要求网站或其他服务的访问者进入www.companyB.com，或等效；或
  • companyB.com在端口 443 上禁用对机器的访问，导致 OutlookcompanyB.com在交换证书并继续之前拒绝URL；或者
  • 修复证书companyB.com以确保companyB.com在该证书上列出，并且尝试https://companyB.com在标准浏览器中访问不会失败。

  无论是否companyB.com解析到 Exchange Server，以上均适用；如果 Outlook 可以与其通信，它稍后会发现该/Autodiscover/Autodiscover.xml路径产生 HTTP 404 错误（不存在）并继续。

• 如果https://autodiscover.companyB.com/... URL 解析为 Exchange Server（或任何其他服务器），但同样autodiscover.companyB.com未列为公用名或主题备用名称，您将观察到此行为。它可以通过固定证书被固定如上，或为你正确地表示，则可以使用一个SRV记录到Outlook重定向到其中URL是列出的证书上并观可以与之通信。

您可能解决此问题的方法

在这种情况下，典型的解决方法是执行后者；在新的 DNS 提供商中创建 SRV 记录以确保 Outlook 被重定向到autodiscover.companyA.com，因为它在证书上作为 SAN 列出，因此（不考虑任何其他问题）将成功运行。为此，您需要：

• _autodiscover._tcp.companyB.com根据文档配置SRV 记录。
• 删除autodiscover.companyB.com主机记录（如果存在），以防止 Outlook 解决此问题并尝试以这种方式访问​​自动发现。
• 还要解决https://companyB.com上述HTTPS 访问的任何问题，因为 Outlook 将在使用 SRV 记录方法之前枚举从用户的电子邮件地址派生的 URL 。

*自动发现如何工作（对于内部加入域的客户端）？

我添加这只是为了完整性，因为这是出现这些证书提示的另一个常见原因。

在加入域的客户端上，当它位于 Exchange 环境的本地（即在内部 LAN 上）时，不会使用上述技术。相反，Outlook 直接与 Active Directory 中的服务连接点（在 Exchange 客户端访问设置中列出）通信，后者列出了 Outlook 可以在其中找到自动发现服务的 URL。

在这些情况下出现证书警告是很常见的，因为：

• 为此目的配置的默认 URL 是指Exchange的内部URL，它通常与公共 URL 不同。
• SSL 证书可能不会在其上列出内部 URL。目前，您的确实如此，但对于使用.local和类似非全球 gTLD 域名后缀的Active Directory 域，这可能会成为未来的问题，因为ICANN 的决定禁止在 2016 年后为此类域颁发 SSL 证书。
• 内部地址可能无法解析为正确的服务器。

在这种情况下，问题是通过更正记录的 URL 以引用正确的外部地址（在证书中列出）来解决，方法是Set-ClientAccessServer使用-AutodiscoverServiceInternalUri交换机运行cmdlet 。执行此操作的各方通常还配置水平分割 DNS，因为他们的网络配置要求他们这样做和/或在上游解析器/连接中断的情况下解析的连续性。