具有SubjectAlternativeName(SAN)的证书在Google Chrome中提供ERR_CONNECTION_RESET

时间:2018-02-10 01:57:50

标签: google-chrome ssl https pki ca

有一个非面向公众的应用程序。我正在努力确保没有与HTTPS相关的警告/错误。

  • 将证书带入SAN字段(由受信任的CA签名)后收到的错误是Web应用程序根本无法加载,即谷歌Chrome(最新)抛出 ERR_CONNECTION_RESET < / strong>即可。这是我得到的唯一错误。 Firefox / Safari工作正常。

  • 相比之下,具有SAN字段的自签名证书不会导致HTTPS错误(与SAN相关的警告);由于证书是自签名的,我不会谈论我得到的其他错误。

  • 我看到的异常是证书链中的根证书(一级上升;总共有两级深度),如果是受信任的CA签名证书,则没有任何SAN字段在它。

  • 我没有尝试修复该部分(不确定是否可以修复,因此不会说太多),即将SAN字段附加到根证书。在我采取更多行动之前,我想先谈谈这件事。

  • 应用程序(需要带有SAN的证书)是非公开的,即SAN字段的DNS条目包含一个不可公开解析的域名地址(不应该是问题直到我的浏览器可以解决它?)。

任何形式的见解都非常有帮助。如果需要澄清,请建议。

P.S。

一些更新:

  • 我想测试一个带有X509扩展(SAN,密钥用法)的openssl生成的自签名CA是否会出错。有趣的是,它没有给出Chrome错误。它应该正常工作(除了自签名错误,这不是一个关注的问题)。
  • 在Windows操作系统中打开证书文件并检查扩展程序后,自签名证书的密钥用法密钥加密,数据加密(30),并且已标记但是,对于CA签名(Microsoft Active Directory证书服务),它不是关键的,它是数字签名,密钥加密(a0),它被标记为关键。
  • 为了排除这可能是密钥用法被标记为关键的问题,我使用该X509扩展程序生成了一个自签名证书(再次使用 openssl )标记为关键。有趣的是,它也运行良好。在这种情况下,我得到的唯一错误是证书是自签名的。
  • 当CA返回请求的签名证书时,会在证书中添加许多其他X509非关键扩展。我不认为这是一个问题,但是,这可能是一个关键的密钥用法扩展以及那些非关键扩展可能会导致失败的原因。
  • 对于TLS握手,根本没有来自服务器端的回复。

认为这可能是CA签名证书中任何相关编码的问题,这是否公平?

此帖子现在跟进Serverfault

1 个答案:

答案 0 :(得分:0)

CA签名证书应该是PEM / Base64格式。它更像是DER格式。改变它解决了问题。