在 Outlook 中專門或 ITAR Office 365 環境中的 「 安全性憑證的名稱不正確,或與網站名稱不相符 」 錯誤

請注意--重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,且可能由 Microsoft Community 利用 Community Translation Framework技術或人工進行事後編修。翻譯過程並無專業譯者參與。Microsoft 同時提供使用者人為翻譯、機器翻譯及社群編修後的機器翻譯三種版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,所有翻譯文章都可能不盡完美,內容都可能出現詞彙、語意或文法上的錯誤。就翻譯內容之不正確或錯誤,或客戶因使用翻譯內容所產生的任何損害,微軟不負擔任何責任。Microsoft將依合理的商業努力不斷地更新機器翻譯軟體和工具,以期能為使用者提供更好的服務。

按一下這裡查看此文章的英文版本:2772058
徵狀
在專用或手臂規定 (ITAR) Microsoft Office 365 環境中的國際流量,系統會提示使用者的安全性警示] 對話方塊,其中包含下列的錯誤訊息:

安全性憑證的名稱不正確或不符合的站台名稱。
例如,安全性警訊 對話方塊類似下列:



在下列情況下,可能會發生這個問題:
  • 使用者嘗試在 Microsoft Office Outlook 中建立新的設定檔。
  • 使用者嘗試啟動 Outlook 用戶端。
  • 當執行 Outlook 用戶端問題會間歇性地發生。

如果使用者按一下 [],使用者可以繼續作業。不過,如果使用者按一下 [],自動探索查閱將會失敗。自動探索查閱失敗可避免下列功能工作如預期般運作:
  • 自動建立 Outlook 設定檔使用自動探索
  • 郵件答錄機 (OOF) 助理員
  • 空閒/忙碌資訊
發生的原因
通常,當您嘗試存取的 URL 不列出主旨或網站的安全通訊端層 (SSL) 憑證主旨替代名稱 (SAN) 中時,就會發生這個問題。雖然不同的組織設定可能會有些許的不同,這個問題通常是因為組織的自動探索網域名稱系統 (DNS) 記錄設定不正確。
解決方案

若要解決這個問題,您可能要變更自動探索 DNS 記錄 (內部、 外部、 或兩者)。不過,這些變更應該經過輕忽,因為自動探索功能無法運作,如果 DNS 記錄設定不正確。

變更自動探索 DNS 記錄之前,您應該瞭解的 Outlook 用戶端會試著找出自動探索服務。Outlook 用戶端會嘗試找出的自動探索服務藉由使用下列的基本順序的作業。不過,在步驟而自動探索服務位於有所不同部署。這個位置取決於是否先方案中有共存且什麼特定先電子郵件環境為 (例如,先 Microsoft Exchange Server、 場所在 Lotus Notes 中或另一個環境)。


下表會顯示基礎的 Outlook 用戶端如何找出自動探索服務的作業順序:
1
  1. 服務連線點 (SCP) 物件的內部的連線。
  2. Outlook 用戶端會嘗試尋找的 SCP 物件所傳回的 URL 的 A 記錄。
2
  1. 使用者的 SMTP 網域。(例如,https://proseware.com)
  2. Outlook 用戶端會嘗試找出使用者的 SMTP 網域 A 記錄。
3
  1. 使用者的 SMTP 網域都會加上自動探索。(例如,https://autodiscover.proseware.com)
  2. Outlook 用戶端會嘗試找出 A 記錄會附加具有自動探索的 url。
4
  1. Outlook 用戶端會嘗試找出 DNS 服務符合使用者的 SMTP 網域的 DNS 區域中的自動探索服務 (SRV) 記錄。(例如,_autodiscover._tcp.proseware.com)
  2. SRV 記錄在某種解析記錄必須存在,例如 A 記錄或 CNAME 記錄,則會傳回另一個 URL。
5結果 如果自動探索服務找不到任何一種方法,自動探索就會失敗。
總之,或許可以解決自動探索服務使用 A 記錄、 CNAME 記錄或 SRV 資料錄。如果要判斷目前使用的記錄,請執行下列命令,在命令提示字元,或在 Windows PowerShell 中:
  1. 若要找出 A 記錄,請執行下列命令:
    1. nslookup
    2. Set Type = A
    3. Autodiscover.SMTPDomain.com
  2. 若要找出 SRV 記錄,請執行下列命令:
    1. nslookup
    2. Set Type = SRV
    3. _autodiscover._tcp.SMTPDomain.com
在下列範例中,Outlook 用戶端可以找出自動探索服務,藉由使用 A 記錄的自動探索 URL,在上表中的步驟 3 中所述:
autodiscover.proseware.com
不過,如我們所述 〈 原因 〉 一節中,這個 URL 的自動探索服務所使用的 SSL 憑證 SAN 中未列出。例如,請參閱下列螢幕擷取畫面:



若要解決這個問題,請使用下列方法。

取代現有資料錄,藉由使用 SRV 記錄指向已存在的 SSL 憑證 SAN 中的命名空間

這是慣用的解決方法,在目前的服務設計,因為現有的 SSL 憑證並沒有更新和部署。依據本節稍早列出的作業的基本順序,組織可能使用受控制和測試的方法,可以防止中斷的自動探索服務來實作新的記錄。

若要解決這個問題,請依照下列步驟執行:
  1. 建立新的 SRV 記錄。

    符合使用者的 SMTP 網域的 DNS 區域中,應該建立 SRV 記錄。SRV 記錄應該具有下列屬性:
    • 服務: _autodiscover
    • 通訊協定: _tcp
    • 連接埠: 443
    • 主機: 重新導向的 URL。這個 URL 可能是 Outlook Web Access (OWA) URL,因為已解析的 IP 應該自動探索服務一樣。此外,這可能會不同部署。
  2. 您移除現有的資料錄之前,新的 SRV 記錄應該經過測試,藉由變更重新導向目前使用者的主應用程式檔案不正確的 IP 資料錄。這項測試可以驗證新的 SRV 記錄正在如預期般至整個組織部署新的 DNS 記錄之前。

    附註當 Outlook 用戶端使用 SRV 記錄時,使用者可能會收到下列訊息,指示即將發生重新導向的使用者。我們建議 userselect不要問我關於此網站一次] 核取方塊,讓訊息不會再顯示。

  3. 當如預期般的運作方式的 SRV 記錄時,您可以移除現有的 DNS 記錄。

其他相關資訊
如需有關自動探索服務的詳細資訊,請移至下列 Microsoft TechNet 網站:

警告:本文為自動翻譯

內容

文章識別碼:2772058 - 最後檢閱時間:12/05/2014 16:59:00 - 修訂: 3.0

Microsoft Business Productivity Online Dedicated, Microsoft Business Productivity Online Suite Federal

  • vkbportal226 kbgraphxlink kbmt KB2772058 KbMtzh
意見反應