變更 Microsoft Edge 瀏覽器 TLS 伺服器憑證驗證
當Microsoft Edge 建立 HTTPS 伺服器的連線時，Edge 會確認伺服器已呈現由瀏覽器信任的實體所簽發的憑證。 此信任關係是透過 憑證信任清單 建立，負責執行檢查的元件稱為 憑證驗證程式。
在舊版的 Microsoft Edge 中，預設憑證信任清單和憑證驗證程序邏輯都是由基礎操作系統 (OS) 平臺所提供。
針對受管理的裝置，從 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) 。 此跟證書程式會定義隨附於 Windows Microsoft清單。 因此，客戶應該不會看到任何使用者可見的變更。
在 macOS 上，如果憑證是由平臺信任的跟證書所簽發，而不是由Microsoft的受信任跟證書計劃所簽發，則憑證就不再受信任。 這種缺乏信任並非常見的情況，因為大部分的伺服器都已確保其使用的 TLS 憑證受到 Microsoft Windows 信任。
更新會以Microsoft受信任根程式 的版本資訊 中所述的步調發行。
推出時程表和測試指引
從 Microsoft Edge 109 開始， (MicrosoftRootStoreEnabled) 的企業原則，以及 edge://flags (「Microsoft根存放區」中的旗標 ) 可用來控制何時使用內建的根存放區和憑證驗證器。
未受企業管理的裝置已開始透過受控功能推出 (CFR) 在 Microsoft Edge 109 中接收功能，且在 Edge 111 中達到 100% 的非受控裝置。 如需詳細資訊， 請參閱Microsoft Edge 設定和實驗，其中說明 Microsoft Edge 中的 CPR 如何運作。 針對企業管理的裝置，現有的平臺提供的實作是透過 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 。 不要指定空白清單，而是完全省略它。
Windows 上的已知撤銷檢查行為差異
除了更嚴格的 RFC 5280 需求之外，新的驗證程式 不 支援以 LDAP 為基礎的證書吊銷清單 (CRL) URI。
如果您的企業啟用 RequireOnlineRevocationChecksForLocalAnchors 原則，且每個 RFC 5280 的 CRL 無效，您的環境可能會開始看到 ERR_CERT_NO_REVOCATION_MECHANISM 和/或 ERR_CERT_UNABLE_TO_CHECK_REVOCATION 錯誤。
如果您遇到 ERR_CERT_NO_REVOCATION_MECHANISM，您應該確認憑證所指定 URI 的 CRL 會傳回 DER 編碼 (不是 PEM 編碼) 回應。