當 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 根存放區”) 中的旗標，可用來控制何時使用內建根存放區和憑證驗證器。
不受企業管理的裝置開始透過 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 位址的 8 個八位元組，以及 IPv6 位址的 32 個八位元組。 如果您的憑證指定空的 IP 位址，您應該重新發行憑證，並完全省略 IP 位址名稱限制。
- 具有空白「排除」清單的名稱限制無效。 Windows 憑證檢視器會在詳細資料中
Name Constraints顯示Excluded=None此清單。 如需詳細資訊，請參閱Chromium問題1457348以取得更多詳細資訊。 不要指定空白清單，而是完全省略它。
Windows 上的已知撤銷檢查行為差異
除了更嚴格的 RFC 5280 需求之外，新的驗證器 不 支援 LDAP 型憑證撤銷清單 (CRL) URI。
如果您的企業啟用 RequireOnlineRevocationChecksForLocalAnchors 原則，且 CRL 根據 RFC 5280 無效，您的環境可能會開始看到 ERR_CERT_NO_REVOCATION_MECHANISM 和/或 ERR_CERT_UNABLE_TO_CHECK_REVOCATION 錯誤。
如果遇到 ERR_CERT_NO_REVOCATION_MECHANISM，您應該確認憑證所指定 URI 的 CRL 會傳回 DER 編碼 ( 而不是 PEM 編碼的) 回應。