變更 Microsoft Edge 瀏覽器 TLS 伺服器憑證驗證

發行項
09/02/2023

注意

商務用 Microsoft Edge 現已在 Edge 穩定版本 116 中提供！深入瞭解原生企業級安全性、生產力、管理性和 AI 內建的新專用工作體驗。

當 Microsoft Edge 建立 HTTPS 伺服器的連線時，Edge 會確認伺服器已呈現由瀏覽器信任的實體所簽發的憑證。此信任關係是透過 憑證信任清單 建立，負責執行檢查的元件稱為 憑證驗證程式。

在舊版的 Microsoft Edge 中，預設憑證信任清單和憑證驗證程式邏輯都是由基礎作業系統 (作業系統) 平臺所提供。

針對受控裝置，從 Windows 和 macOS 上的 Microsoft Edge 112 開始，預設憑證信任清單和憑證驗證程式都是由瀏覽器提供並隨附。這種方法會將清單和驗證程式與主機作業系統的根存放區分離，以進行預設驗證行為。如需變更時間的詳細資訊，請參閱推出時程表和測試指引。

即使在變更之後，除了信任隨附于 Microsoft Edge 的內建根目錄之外，瀏覽器也會查詢基礎平臺，以取得使用者和/或企業安裝的本機安裝根目錄。因此，使用者或企業將更多根目錄安裝到主機作業系統根存放區的案例應該會繼續運作。

這項變更表示憑證驗證邏輯在 Windows 和 macOS 上的 Microsoft Edge 中一致地運作。在未來要決定的版本中，推出也會套用至 Linux 和 Android。由於 Apple App Store原則，Apple 提供的根存放區和憑證驗證程式會繼續在 iOS 和 iPadOS 上使用。

預設憑證信任清單來源

Windows 和 macOS 上隨附于 Microsoft Edge 的根存放區來自 Microsoft 受信任根憑證計畫所定義的憑證信任清單 (CTL) 。此根憑證程式會定義隨附于 Microsoft Windows 的清單。因此，客戶應該不會看到任何使用者可見的變更。

在 macOS 上，如果憑證是由平臺所信任但不受 Microsoft 受信任根憑證計畫所信任的根憑證所簽發，則憑證就不再受信任。這種缺乏信任並非常見的情況，因為大部分的伺服器都已確保他們使用的 TLS 憑證受到 Microsoft Windows 信任。

更新會以 Microsoft 受根信任計畫版本資訊中所述的步調發行。

推出時程表和測試指引

從 Microsoft Edge 109 開始，企業原則 (MicrosoftRootStoreEnabled) ，以及 edge://flags (「Microsoft Root Store」中的旗標 ) 可用來控制使用內建根存放區和憑證驗證器的時機。

未受企業管理的裝置已開始透過 Microsoft Edge 109 中的受控功能推出 (CFR) 接收功能，且在 Edge 111 中達到 100% 的非受控裝置。如需詳細資訊，請參閱 Microsoft Edge 設定和實驗，其中說明 Microsoft Edge 中 CFR 的運作方式。針對企業管理的裝置，現有的平臺提供的實作是透過 Microsoft Edge 111 使用。

從 Microsoft Edge 112 開始，所有 Windows 和 macOS 裝置的預設值已變更，包括企業管理的裝置，以使用隨瀏覽器隨附的驗證器實作和 CTL。 MicrosoftRootStoreEnabled原則會繼續在此版本中提供，以允許企業在發現非預期的問題時還原為先前的行為，並將問題回報給 Microsoft。

Microsoft 建議擁有中斷和檢查 Proxy 的企業，或其他涉及根目錄所簽發之 TLS 伺服器憑證的案例，不在 Microsoft CTL 中，主動識別並回報任何相容性問題給 Microsoft。

在 Microsoft Edge 115 中，已移除 對 MicrosoftRootStoreEnabled 原則的支援。

Windows 上已知本機信任的憑證行為差異

更嚴格的 RFC 5280 合規性

新的內建憑證驗證程式在強制執行 RFC 5280 需求方面比舊的平臺型驗證器更為嚴格。

更嚴格的 RFC 5280 合規性範例包括：

ECDSA 演算法的演算法參數必須不存在。當新驗證程式拒絕憑證時，舊的驗證程式會忽略參數。如需詳細資訊，請參閱Chromium問題1453441。
指定 IP 位址的名稱條件約束必須包含 IPv4 位址的八位八位，以及 IPv6 位址的 32 個八位。如果您的憑證指定空的 IP 位址，您應該重新發出憑證，並完全省略 IP 位址名稱條件約束。
具有空白「排除」清單的名稱條件約束無效。 Windows 憑證檢視器會在詳細資料中 Name Constraints 顯示此清單 Excluded=None 。如需詳細資訊，請參閱Chromium問題1457348。不要指定空白清單，而是完全省略它。

應用程式原則延伸模組

在 Microsoft Edge 115 之前，新的驗證程式不支援 CertGetEnhancedKeyUsage 函式檔中所述的僅限 Windows「應用程式原則」延伸模組欄位。在 Microsoft Edge 115 中，已進行更新以忽略擴充功能。如需詳細資訊，請參閱Chromium問題1439638。

此延伸模組會使用物件識別碼 (OID) 1.3.6.1.4.1.311.21.10 。如果憑證包含此延伸模組，並將它標示為重大，則連線會失敗並出現 ERR_CERT_INVALID 。

您可以使用下列其中一種方式來檢查此案例是否適用于您的憑證：

透過擷取 about:net-export 的網路記錄檔包含中的 CERT_VERIFIER_TASK 字串 ERROR: Unconsumed critical extension ，且 OID 值為 2B060104018237150A 。
使用 Windows 憑證檢視器開啟憑證。在 [顯示] 篩選中，選取 [僅限重大延伸模組]。檢查是否有 [應用程式原則] 欄位存在。
使用 certutil.exe-dump 參數執行並檢閱輸出，以檢查是否有重要的應用程式原則延伸模組欄位。

如果您的憑證目前使用此延伸模組，請確定它現在可在 Microsoft Edge 115 中運作。或者，重新發出憑證，並改為只依賴增強金鑰使用量欄位 (OID 2.5.29.37) 來指定允許的使用方式。

Windows 上的已知撤銷檢查行為差異

除了更嚴格的 RFC 5280 需求之外，新的驗證程式不支援以 LDAP 為基礎的憑證撤銷清單 (CRL) URI。

如果您的企業啟用 RequireOnlineRevocationChecksForLocalAnchors 原則，且每個 RFC 5280 的 CRL 無效，您的環境可能會開始看到 ERR_CERT_NO_REVOCATION_MECHANISM 和/或 ERR_CERT_UNABLE_TO_CHECK_REVOCATION 錯誤。

在 Microsoft Edge 114 之前，新的Chromium型驗證程式會強制執行 CRL 的「基準需求」最大年齡。針對分葉撤銷，目前的存留期上限為 7 天，而中繼撤銷的目前最大存留期為 366 天。檢查目前的時間減去「此更新」 (「生效日期」) 未超過這些最大值，即可執行檢查。在 Microsoft Edge 114 中，不再針對非公開信任的憑證強制執行這些需求。如需詳細資訊，請參閱Chromium問題971714。

由於新的驗證程式會透過瀏覽器的網路堆疊下載撤銷資訊，因此也會套用 HTTP Strict Transport Security (HSTS) 升級。如果主機已設定 HSTS pin，此升級可能會與透過 HTTP 裝載 CRL 資訊的需求不相容 (而非 HTTPS) 。如果此案例對您的環境造成負面影響，建議您透過Chromium問題1432246分享影響的詳細資訊。

如果您遇到 ERR_CERT_NO_REVOCATION_MECHANISM ，您應該確認憑證所指定 URI 的 CRL 會傳回 DER 編碼 (不是 PEM 編碼) 回應。

如果您遇到 ERR_CERT_UNABLE_TO_CHECK_REVOCATION 錯誤，您應該確認憑證簽發者也是 CRL 簽發者、未設定憑證的欄位、裝載 CRL 的 cRLIssuer URI 都使用 HTTP 通訊協定，而且不在設定為使用 HSTS 的主機上，而且最近發出的 CRL 已足夠。