对 Microsoft Edge 浏览器 TLS 服务器证书验证的更改
当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) 。 此根证书程序定义 windows Microsoft 附带的列表。 因此，客户应该不会看到用户可见的更改。
在 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建议具有中断和检查代理或其他涉及由根颁发的 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 编码) 响应。