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

运行Exchange 2007和IIS6.0的SBS 2008

公司A有两家在同一屋檐下经营的公司。 为了适应电子邮件,我们有3个Exchange帐户每个用户来pipe理这个。 所有用户使用他们的公司A帐户login到域。

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

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

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

远程访问公司C电子邮件地址的用户告诉我,这从来没有发生过。 这开始于首席执行官自己改变DNS提供商,并在这个过程中原来的DNS设置丢失。 他提到了一些正在创build的SRVlogging,这个logging纠正了这个问题,但这是关于它的。

寻找如何正确解决这个问题的指导。

此问题最有可能是由Outlook的自动发现服务引起的,这是Outlook无处不在function的一部分。 自动发现为最终用户的Outlook客户端提供了各种服务提供的各种信息,这些服务由Exchange提供,可以放在哪里; 这是用于各种目的:

  • 在首次运行的Outlook上自动configurationOutlookconfiguration文件,由于其他信息是自动定位和检索的,因此只能使用用户的电子邮件地址和密码来configurationExchange帐户。

  • Outlook客户端访问的基于Web的服务的dynamic位置,包括外出助理,统一消息function,Exchange控制面板(ECP)的位置等。

这是微软专有的RFC 6186实现。 不幸的是,他们并没有真正遵循在Outlook Anywhere的devise中的RFC的build议,但这也许是可以预料的,因为Exchange和RPC over HTTPSfunction不是传统的IMAP / SMTP服务器。


自动发现如何工作(对于外部*用户)?

自动发现与path为/Autodiscover/Autodiscover.xml的客户端访问服务器上的Web服务(在这种情况下,所有angular色位于SBS服务器上)进行/Autodiscover/Autodiscover.xml ,并以其默认Web站点为根。 来定位与,它删除的电子邮件地址的用户部分进行通信的服务器的FQDN,留下结构域(即@ companyB.com)。 它会尝试使用以下每个URL与Autodiscover进行通信:

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

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

最后,使用DNS中的服务logging(SRV)进行后续检查,该服务logging位于companyB.com命名空间以外的众所周知的位置,并可将Outlookredirect到服务器正在侦听的正确URL。


什么可以出错?

在这个过程中会出现几个问题之一:

没有DNS条目

通常,域( companyB.com )的根目录可能无法parsing为DNS中的主机logging。 不正确的DNSconfiguration(或有意识的决定不公开Outlook Anywhere服务)可能意味着autodiscover.companyB.comlogging也不存在。

在这些情况下,没有重大问题。 Outlook只是继续使用最后一次已知的configuration与Exchange进行通信,并且可能会因某些基于Web的function(它需要通过自动发现(例如外出助理)检索URL)而降级。 解决方法是使用Outlook Web Access访问此类function。

在新的Outlookconfiguration文件中自动configurationExchange帐户也不是自动的,并且需要手动configurationRPC over HTTPS设置。 但是,这不会导致你描述的问题。

有问题的SSL证书

这是完全有可能的URL Outlook用来尝试联系Exchange服务器parsing为主机,可能会或可能不会是一个客户端访问服务器。 如果Outlook可以与该服务器上的端口443进行通信,证书当然可以交换以build立Outlook和远程服务器之间的安全通道。 如果URL Outlook认为它正在与之交谈,但未在该证书上列出,则可以将其作为通用名称或主题替代名称(SAN) – 这将引发Outlook展示您在初始文章中描述的对话框。

发生这种情况的原因可能有几个,一直到如何configurationDNS以及如何通过Outlook检查上面描述的URL:

  • 如果https://companyB.com/ … URLparsing为主机logging, 并且该地址的Web服务器在端口443上侦听, 并且它具有不以通用名称列出companyB.com的SSL证书,使用替代名称,那么问题就会发生。 不pipe主机是不是Exchange Server, 它可能是托pipe公司网站的networking服务器,没有正确configuration。 也可以:

    • 禁止在根目录下的主机loggingcompanyB.com区(要求访问者访问本网站或其他服务进入www.companyB.com ,或同等学历;
    • 禁止访问本机在companyB.com端口443,导致Outlook拒绝companyB.com URL证书交换之前,继续前进; 要么
    • companyB.com上修复证书以确保companyB.com在证书上列出,并且在标准浏览器中访问https://companyB.com尝试不会失败。

    无论companyB.com是否parsing为Exchange Server,以上都适用。 如果Outlook可以与它进行通信,它将在以后发现/Autodiscover/Autodiscover.xmlpath产生一个HTTP 404错误(不存在),并继续前进。

  • 如果https://autodiscover.companyB.com/ … URLparsing为Exchange Server(或任何其他服务器),但同样, autodiscover.companyB.com未列为常用名称或主题备用名称会观察到这种行为。 可以通过修复证书来解决上述问题, 或者如您正确指出的那样,可以使用SRVlogging将Outlookredirect到证书上列出的URL以及哪些Outlook 可以与之通信。

你可能修复这个问题

在这种情况下,典型的解决办法是做后者; 在新的DNS提供商中创buildSRVlogging,以确保Outlook被redirect到autodiscover.companyA.com ,除了任何其他问题,它将在证书上列为SAN,从而成功运行。 为此,您需要:

  • 根据文档configuration_autodiscover._tcp.companyB.com SRVlogging。
  • 删除autodiscover.companyB.com主机logging(如果存在),以防止Outlook解决此问题并尝试以这种方式访问​​Autodiscover。
  • 还要解决HTTPS访问https://companyB.com遇到的任何问题,因为Outlook将会列举从用户的电子邮件地址派生的URL, 然后再转到SRVlogging方法。

*自动发现如何工作(对于内部的,join域的客户端)?

我只是为了完整而添加这个,因为这是证书提示发生的另一个常见原因。

上join域的客户端,当它是本地的Exchange环境(即,在内部LAN),不使用上述技术。 相反,Outlook直接与Active Directory中的服务连接点(在Exchange客户端访问设置中列出)进行通信,该列表列出了Outlook可以find自动发现服务的URL。

在这种情况下发生证书警告是很常见的,因为:

  • 为此configuration的默认URL指的是Exchange的内部 URL,通常与公用URL不同。
  • SSL证书不能在其上列出内部URL。 目前,您的确有这样做,但是由于ICANN决定禁止在2016年后发布此类域名的SSL证书,因此使用.local和类似的非全球gTLD域名后缀的Active Directory域可能会成为未来的问题。
  • 内部地址可能无法parsing到适当的服务器。

在这种情况下,通过使用-AutodiscoverServiceInternalUri开关运行Set-ClientAccessServer cmdlet,通过更正logging的URL来引用正确的外部地址(在证书中列出)来解决此-AutodiscoverServiceInternalUri 。 执行此操作的各方通常也会configuration水平分割DNS ,因为它们需要通过其networkingconfiguration进行configuration和/或在上游parsing器/连接中断的情况下继续parsing。

您需要在域B和C中创build一个与cert(autodiscover.companyA.com)中的某个名称匹配的SRVlogging。 这告诉Outlook,该名称处理域B和C的自动发现

请阅读DNS部分中的SRVlogging:

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/