是的，Chrome已经推出了own certificate root store。他们说这在Chrome 105中就发生了，但我们从Chrome 106开始在企业环境中才开始遇到问题。
在Windows上，您可以通过注册表禁用此新功能：
1.在HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome中创建一个注册表双字节值ChromeRootStoreEnabled = 0
1.重新启动Chrome
但是不要忘记，在不了解你所做的事情的情况下禁用这个功能可能会带来安全风险-在这种情况下不是很大，但无论如何。
这些文档实际上说明了新的根存储区考虑了本地受信任的证书：
Chrome证书验证器在证书验证过程中考虑本地管理的证书。这意味着如果企业将根CA证书作为可信证书分发给其用户（例如，通过Windows组策略对象），则该证书在Chrome中将被视为可信证书。
我们在企业环境中使用自己的CA来签署测试网站的HTTPS证书。所以我们看起来一定没有受到影响。但是即使开发团队中的每个人都将我们的CA安装在受信任的根目录中-我们仍然面临这个问题。我不确定这是一个bug还是有其他我们需要知道的关于哪些CA被接受哪些不被接受的东西。

更新日期：2022年10月24日

我发现除了我们团队的CA之外，还有另一个本地企业CA。由该CA颁发的认证被Chrome接受，而不会禁用新的根存储-所以Chrome显然不会忽略本地信任的证书。
经过反复试验，我发现问题与CA证书无关，而是与 * 端点CA签名证书 * 有关。现在被拒绝的旧测试证书包含以下属性：

• Basic Constraints：主题=不是CA，路径长度= 0
• Key Usage：数字签名、密钥加密
• Extended Key Usage：TLS服务器、TLS客户端+ 9个内部自定义OID
• Subject Alternative Name：localhost +大约30个测试网站在不同域中的DNS名称

删除Basic Constraints属性使Chrome最终接受了证书。
因此，除了新的根存储区之外，证书验证过程还有更多的变化。到目前为止，我还没有找到任何文档说明他们到底改变了什么。AFAIK Basic Constraints是一个absolutely fine property，即使在非CA证书中也有，所以在我看来，它像是Chrome中的一个bug。