Office TLS 憑證變更
Microsoft 365 正在更新支援傳訊、會議、電話語音、語音以及視訊的服務,以使用來自不同根憑證授權單位 (CA) 的 TLS 憑證。 完成此變更的原因在於目前的根 CA 將於 2025 年 5 月到期。
受影響的產品包括:
- Microsoft Teams
- Skype
- 商務用 Skype Online
- Microsoft Dynamics 365
- GroupMe
- Kaizala
- AzureAzure 通訊服務
受影響的端點包括 (但不僅限於):
- *.teams.microsoft.com
- *.skype.com
- *.skypeforbusiness.com
- *.groupme.com
- *.communication.azure.com
- *.operatorconnect.microsoft.com
此外,美國政府國家雲端實例 Microsoft 365 中的 Teams 和 商務用 Skype Online 端點也會進行相同的變更,影響端點,例如:
- *.gcc.teams.microsoft.com
- *.dod.teams.microsoft.us
- *.gov.teams.microsoft.us
- *.online.dod.skypeforbusiness.us
- *.online.gov.skypeforbusiness.us
- *.um-dod.office365.us
- *.um.office365.us
這項變更不會影響用於中國或德國國家雲端實例 Microsoft 365 的憑證、網域或服務。
這篇文章中的所有憑證資訊之前在 2020 年 10 月之前的 Microsoft 365 加密鏈中已經提供。
提示
如果您不是 E5 客戶,請使用 90 天的 Microsoft Purview 解決方案試用版來探索其他 Purview 功能如何協助貴組織管理數據安全性與合規性需求。 立即從 Microsoft Purview 合規性入口網站 試用中樞開始。 瞭解 有關註冊和試用版條款的詳細數據。
何時會發生這項變更?
服務在 2022 年 1 月開始轉換至新的根 CA,並會持續到 2022 年 10 月。
有哪些變更?
目前 Microsoft 365 服務所使用的大部分 TLS 憑證都會鏈結至以下根 CA:
CA 的一般名稱 | 指紋 (SHA1) |
---|---|
Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
具有下列其中一個中繼 CA:
CA 的一般名稱 | 指紋 (SHA1) |
---|---|
Microsoft RSA TLS CA 01 | 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a |
Microsoft RSA TLS CA 02 | b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 |
Microsoft 365 服務所使用的新 TLS 憑證現在將鏈結至下列其中一項根 CA:
CA 的一般名稱 | 指紋 (SHA1) |
---|---|
DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
2017 年 Microsoft RSA 根憑證授權單位 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
2017 年 Microsoft ECC 根憑證授權單位 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
具有下列其中一個中繼 CA:
CA 的一般名稱 | 指紋 (SHA1) |
---|---|
Microsoft Azure TLS 核發 CA 01 | 2f2877c5d778c31e0f29c7e371df5471bd673173 |
Microsoft Azure TLS 核發 CA 02 | e7eea674ca718e3befd90858e09f8372ad0ae2aa |
Microsoft Azure TLS 核發 CA 05 | 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5 |
Microsoft Azure TLS 核發 CA 06 | 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0 |
例如,這是具有其中一個新憑證鏈結的有效憑證:
此變更對我有何影響?
根 CA「DigiCert Global Root G2」廣受 Windows、macOS、Android 以及 iOS 等作業系統以及諸如 Microsoft Edge、Chrome、Safari 和 Firefox 等瀏覽器所信賴。 我們預期大部分 Microsoft 365 顧客將不會受到影響。
但是,如果您的應用程式有明確指定可接受的 CA 清單,您的應用程式有可能受影響。 這項做法稱之為「憑證關聯」。 顧客的可接受 CA 清單中如果沒有新的根 CA,將收到憑證驗證錯誤訊息,這可能會影響您應用程式的可用性或功能。
以下是一些偵測您的應用程式是否可能受影響的方式:
在您的原始程式碼中搜尋在此處找到的任何中繼 CA 的指紋、一般名稱或其他屬性。 如果有相符項目,則您的應用程式將受到影響。 若要解決此問題,請更新原始程式碼,以加入新 CA 的屬性。 最佳做法是確保可在短期內新增或編輯 CA。 產業法規要求,部分情況下必須在七天內替換 CA 憑證,因此實施憑證關聯的應用程式必須快速回應這些變更。
.NET 會公開
System.Net.ServicePointManager.ServerCertificateValidationCallback
和System.Net.HttpWebRequest.ServerCertificateValidationCallback
回撥功能,這讓開發人員能利用自訂邏輯來判斷憑證是否有效,而不用仰賴標準的 Windows 憑證存放區。 開發人員可新增邏輯以確認特定一般名稱或指紋,或僅允許特定的根 CA,例如,「Baltimore CyberTrust Root」。 如果您的應用程式使用這些回撥功能,您應該確保它對於新舊根和中繼 CA 都能接受。原生應用程式可能會使用
WINHTTP_CALLBACK_STATUS_SENDING_REQUEST
,這讓原生應用程式能實施自訂憑證驗證邏輯。 這種通知的使用方式很罕見,並需要大量的自訂程式碼才能實施。 與上述類似,請確保您的應用程式對於新舊根和中繼 CA 都能接受。如果您使用和 Microsoft Teams、Skype、 商務用 Skype 線上版或 Microsoft Dynamics API,而您不確定它是否使用憑證關聯,則請和應用程式供應商確認。
和 Azure 服務通訊的不同作業系統和程式語言執行階段可能需要完成更多步驟,才能正確建置並驗證新的憑證鏈:
- Linux:許多通訊群組要求您新增 CA 至
/etc/ssl/certs
。 如需具體說明,請參照通訊群組文件。 - Java:確保 Java 金鑰存放區包含上述清單的 CA。
- 在中斷連線的環境中運作的 Windows:在中斷連線的環境中運作的系統將需要將新的根 CA 新增到它們的
Trusted Root Certification Authorities
存放區,以及將新的中繼 CA 新增到它們的Intermediate Certification Authorities
存放區。 - Android:請查看適用於您的裝置和 Android 版本的文件。
- IoT 或內嵌的裝置:電視機上盒之類的內嵌裝置運送時經常會隨附一份有限的根授權單位憑證組,因此無法輕易更新憑證存放區。 如果您為自訂內嵌或 IoT 裝置寫入程式碼或管理其部署,請確保該裝置信任新的根 CA。 您可能需要聯絡裝置的製造商。
- Linux:許多通訊群組要求您新增 CA 至
如果您的環境中防火牆規則僅允許向外撥打電話至特定端點,則請允許下列憑證撤銷清單 (CRL) 或線上憑證狀態通訊協定 (OCSP) 網址:
http://crl3.digicert.com
http://crl4.digicert.com
http://ocsp.digicert.com
http://crl.microsoft.com
http://oneocsp.microsoft.com
http://ocsp.msocsp.com
http://www.microsoft.com/pkiops
如果您受到此變更的影響,依您執行的環境類型以及受影響的情況而定,您可能會看到錯誤訊息。 請檢查 Windows 應用程式事件邏輯、CAPI2 事件邏輯以及自訂應用程式邏輯,以取得類似下面的訊息:
An operation failed because the following certificate has validation errors: Subject Name: CN=teams.microsoft.com Issuer Name: CN=Microsoft Azure TLS Issuing CA 01, O=Microsoft Corporation, C=US Errors: The root of the certificate chain is not a trusted root authority.
如果您使用會話邊界控制器,Microsoft 已備妥測試端點,可用來驗證 SBC 設備信任從新的根 CA 簽發的憑證。 此端點只能用於SIP OPTIONS Ping訊息,而非語音流量。
Global FQDN: sip.mspki.pstnhub.microsoft.com Port: 5061
如果無法正常運作,請連絡您的裝置製造商,以判斷是否有可用的更新來支援新的根 CA。
我何時才能淘汰舊的 CA 資訊?
目前的根 CA、中繼 CA 以及分葉憑證將不會被撤銷。 根據現有憑證的存留期,現有的 CA 一般名稱和/或指紋至少在 2023 年 10 月以前都還需要。
已知問題
在極少數的情況下,企業使用者可能會看到憑證驗證錯誤,其中根 CA “DigiCert Global Root G2” 會顯示為已撤銷。 這是因為在下列兩種情況下,已知的 Windows Bug 所致:
- 根 CA 位於 CurrentUser\Root 證書存儲 中,且遺漏
NotBeforeFileTime
和NotBeforeEKU
屬性 - 根 CA 位於 LocalMachine\AuthRoot 證書存儲 中,但同時
NotBeforeFileTime
具有 和NotBeforeEKU
屬性 - 根 CA 不在 LocalMachine\Root 證書存儲中
在 之後,從這個根 CA NotBeforeFileTime
發出的所有分葉憑證都會顯示為已撤銷。
系統管理員可以檢查 CAPI2 記錄檔以找出此錯誤並進行疑難解答:
Log Name: Microsoft-Windows-CAPI2/Operational
Source: Microsoft-Windows-CAPI2
Date: 6/23/2022 8:36:39 AM
Event ID: 11
Task Category: Build Chain
Level: Error
[...]
<ChainElement>
<Certificate fileRef="DF3C24F9BFD666761B268073FE06D1CC8D4F82A4.cer" subjectName="DigiCert Global Root G2" />
[...]
<TrustStatus>
<ErrorStatus value="4000024" CERT_TRUST_IS_REVOKED="true" CERT_TRUST_IS_UNTRUSTED_ROOT="true" CERT_TRUST_IS_EXPLICIT_DISTRUST="true" />
<InfoStatus value="10C" CERT_TRUST_HAS_NAME_MATCH_ISSUER="true" CERT_TRUST_IS_SELF_SIGNED="true" CERT_TRUST_HAS_PREFERRED_ISSUER="true" />
</TrustStatus>
[...]
<RevocationInfo freshnessTime="PT0S">
<RevocationResult value="80092010">The certificate is revoked.</RevocationResult>
</RevocationInfo>
</ChainElement>
</CertificateChain>
<EventAuxInfo ProcessName="Teams.exe" />
<Result value="80092010">The certificate is revoked.</Result>
請注意專案是否存在 CERT_TRUST_IS_EXPLICIT_DISTRUST="true"
。
您可以執行下列certutil
命令並比較輸出,以確認具有不同NotBeforeFileTime
屬性的根 CA 有兩個復本存在:
certutil -store -v authroot DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
certutil -user -store -v root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
使用者可以藉由執行下列動作,刪除證書儲存中的 CurrentUser\Root
根 CA 複本來解決問題:
certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
或
reg delete HKCU\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 /f
第一種方法會建立一個 Windows 對話框,用戶必須按兩下該對話方塊,而第二種方法則不按兩下該對話方塊。
意見反應
https://aka.ms/ContentUserFeedback。
即將推出:在 2024 年,我們將隨著內容的意見反應機制逐步淘汰 GitHub 問題,並以新的意見反應系統來取代。 如需詳細資訊,請參閱提交並檢視相關的意見反應