Outlook 安全警報 - 安全證書上的名稱無效或與站點名稱不匹配
執行 Exchange 2007 和 IIS6.0 的 SBS 2008
A 公司還有另外兩家在同一屋簷下運營的公司。為了容納電子郵件，我們為每個使用者設置了 3 個 Exchange 帳戶來管理它。所有使用者都使用他們的 CompanyA 帳戶登錄域。
- 公司\使用者 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
- 公司-SBS.local
- autdiscover.companyA.com
遠端訪問 companyC 電子郵件地址的使用者告訴我，這種情況以前從未發生過。這始於 CEO 自行更改 DNS 提供商，在此過程中原始 DNS 設置失去。他提到了一些關於正在創建的 SRV 記錄的內容，該記錄糾正了這個問題，但僅此而已。
尋找有關如何正確解決此問題的指導。
此問題很可能是由 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.xmlhttps://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 伺服器。糾錯：
- 禁用區域根目錄的主機記錄
companyB.com（要求網站或其他服務的訪問者進入www.companyB.com，或等效項；或- 在埠 443 上禁用對電腦的訪問，導致 Outlook在交換證書並繼續之前
companyB.com拒絕URL；或者companyB.com- 修復證書
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 ，Outlook可以與之通信。您對此問題的可能解決方法
在這種情況下，典型的解決方法是執行後者；在新的 DNS 提供程序中創建 SRV 記錄，以確保 Outlook 被重定向到
autodiscover.companyA.com，這（除任何其他問題外）將成功執行，因為它在證書上列為 SAN。為此，您需要：
_autodiscover._tcp.companyB.com根據文件配置SRV 記錄。- 刪除
autodiscover.companyB.com主機記錄（如果存在），以防止 Outlook 解決此問題並嘗試以這種方式訪問自動發現。- 還要解決上述 HTTPS 訪問的任何問題
https://companyB.com，因為 Outlook 將在使用 SRV 記錄方法之前列舉從使用者電子郵件地址派生的 URL。*自動發現如何工作（對於內部、加入域的客戶端）？
我添加它只是為了完整性，因為這是出現這些證書提示的另一個常見原因。
在加入域的客戶端上，當它位於 Exchange 環境的本地（即在內部 LAN 上）時，不使用上述技術。相反，Outlook 直接與 Active Directory 中的服務連接點（列在 Exchange 客戶端訪問設置中）進行通信，該連接點列出了 Outlook 可以找到自動發現服務的 URL。
在這些情況下，證書警告很常見，因為：
- 為此目的配置的預設 URL 是指 Exchange 的內部URL，它通常與公共 URL 不同。
- SSL 證書可能不會在其上列出內部 URL。目前，您的域名確實如此，但這可能會在未來成為使用
.local類似非全球 gTLD 域名後綴的 Active Directory 域的問題，因為ICANN 的一項決定禁止在 2016 年後為此類域頒發 SSL 證書。- 內部地址可能無法解析到正確的伺服器。
在這種情況下，通過使用開關執行
Set-ClientAccessServercmdlet更正記錄的 URL 以引用正確的外部地址（在證書中列出）來解決問題。-AutodiscoverServiceInternalUri這樣做的各方通常也會配置水平分割 DNS，因為他們需要通過其網路配置和/或在上游解析器/連接中斷的情況下保持解析的連續性。