受信任根目录中的Windows自签名证书在Chrome 106中无效

hrirmatl  于 2022-12-06  发布在  Go
关注(0)|答案(1)|浏览(280)

我正在使用powershell New-SelfSignedCertificate创建一个证书并导入到.netcore项目的受信任根目录中。
它一直工作正常,但最近停止了,证书要到2024年才到期。
我用的是Chrome 106。
有什么想法,为什么它会停止和如何修复?

5us2dqdw

5us2dqdw1#

是的,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。

相关问题