有一个非面向公众的应用程序。我正在尝试确保没有与 HTTPS 相关的警告/错误。
我在放入带有 SAN 字段的证书(由受信任的 CA 签名)后收到的错误是,Web 应用程序根本无法加载,即只有 Google Chrome(最新版)会抛出连接重置。这是我遇到的唯一错误。Firefox/Safari 运行正常。
相比之下,带有 SAN 字段的自签名证书不会出现任何 HTTPS 损坏错误(与 SAN 相关的警告);我不会谈论由于证书是自签名而出现的其他错误。
我看到的一个
异常区别是,在受信任的 CA 签名证书的情况下,证书链中的根证书(上一级;总共有 2 个深度级别)没有任何 SAN 字段。我还没有尝试修复该部分(不确定是否可以修复,所以不会多说),即将 SAN 字段附加到根证书。我想先在这里讨论一下,然后再采取更多行动。
该应用程序(需要带有 SAN 的证书)是非公开的,即 SAN 字段的 DNS 条目包含不可公开解析的域地址(在我的浏览器可以解析它之前不应该是问题?)。
任何见解都大有裨益。如果需要澄清,请提出建议。
附言
一些更新:
- 我想测试由 openssl 生成的具有 X509 扩展(SAN、密钥用法)的自签名 CA 是否会出现错误。有趣的是,它没有给出 Chrome 错误。它运行正常(除了自签名错误,目前这不是什么问题)。
- 在 Windows 操作系统中打开证书文件并检查扩展名后,密钥用法自签名证书是密钥加密、数据加密 (30)并且它被标记为非关键,但是,对于 CA 签名(Microsoft Active Directory 证书服务)来说,它是数字签名、密钥加密 (a0)并且被标记为严重。
- 为了排除这是否是一个问题密钥用法由于被标记为关键,我生成了一个自签名证书(再次使用openssl),并将该 X509 扩展标记为关键。有趣的是,它也能正常工作。在这种情况下,我得到的唯一错误是证书是自签名的。
- 当 CA 返回请求的签名证书时,证书中会添加一堆其他 X509 非关键扩展。目前,我认为这不是一个问题,但是,这可能是导致关键密钥用法扩展与那些非关键扩展一起可能会导致失败。
- 对于 TLS 握手,服务器端根本没有任何回复。
是否可以认为这可能是 CA 签名证书中所涉及编码的问题?
答案1
CA 签名的证书应该是 PEM/Base64 格式。但它实际上是 DER 格式。更改它就可以解决问题。
答案2
谷歌和赛门铁克目前正在发生一些争斗 Chrome 计划不再信任赛门铁克证书 您的官方证书是否来自 Symantec 根 CA(或任何连锁组件)?也许您的证书已经有点不受信任了。在这种情况下,根据 Google 的意见,您应该去更值得信赖的 CA。