SSL握手失败 – 包含两个CA签名证书和一个自签名证书的verisign链证书

我坚持一个问题,并试图debugging它。 我们购买了Verisign证书。 当我们使用:

openssl> s_client -connect myweb.com:443 -showcerts 

SSL握手从来没有完成,最后我们看到错误:

 Verify return code: 19 (self signed certificate in certificate chain) 

它显示3 ---BEGIN/END CERTIFICATE---标签。 链中的两个证书是Verisign签名的,但一个是自签名的。

  1. 如果有人能解释这个自签名证书是如何出现在CA签名证书中的?

  2. 这是错误19 (self signed certificate in certificate chain)良性? 如果不是,可能是什么原因造成的?

  3. 客户端在可信存储区中拥有CA证书,但自签名证书没有任何内容。 你认为这可能导致问题? 如果是,我如何:

    1. 如何摆脱链式证书中的自签名证书,只留下2个CA签名的证书链?
    2. 在客户端可信存储上添加这个自签名证书?

CA颁发的根证书只是自签名证书(可能会被用来颁发中间CA证书)。 除了在许多浏览器或操作系统信任定位器上默认导入它们之外,它们对它们没有太多特别之处。

尽pipe浏览器和一些工具被configuration为在默认位置查找可信的CA证书(其中一些可能是自签名的),但据我所知openssl命令不是。

因此,从其最终实体证书(服务器证书)到根CA证书(可能具有中间CA证书)的任何呈现完整证书链的服务器将在链中具有自签名证书:根CA 。

openssl s_client -connect myweb.com:443 -showcerts没有任何特别的理由来信任Verisign的根CA证书,而且由于它是自签名的,你将得到“ 证书链中的自签名证书 ”。

如果你的系统有一个默认信任的证书的位置(我认为RedHat / Fedora上的/etc/pki/tls/certs和Ubuntu / Debian上的/etc/ssl/certs ),你可以configurationOpenSSL使用它作为信任锚,例如像这样:

 openssl s_client -connect myweb.com:443 -showcerts -CApath /etc/ssl/certs 

这听起来像中间证书丢失。 截至2006年4月,威瑞信颁发的所有SSL证书都要求安装中级CA证书。

这可能是因为您没有将整个证书链加载到服务器上。 有些企业不允许他们的电脑下载额外的证书,导致无法完成SSL握手。

以下是关于中间链的一些信息:
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD146

中级CA证书

以下是VeriSign SSL证书安装检查器的链接: https : //knowledge.verisign.com/support/ssl-certificates-support/index? page = content & id = AR1130

input你的URL,点击“testing这个Web服务器”,它会告诉你,如果你的中间证书颁发机构有问题。

关于服务器可以传递给客户端的根证书或不从RFC-5246“传输层安全(TLS)协议版本1.2”文档中提取:

certificate_list
这是证书的一个序列(链)。 发送者的证书必须在列表中首先出现。 以下每个证书都必须直接certificate前面的证书。 由于证书validation要求根密钥是独立分发的,因此指定根证书颁发机构的自签名证书可以从链中省略,在
假定远端必须已经拥有它,以便在任何情况下validation它。

从RFC-2119“最佳实践”中提取关于术语“可能”的说法:

可自我
这个词,或者形容词“可选”,意味着一个项目是真正可选的。 一个供应商可能会select包含该项目,因为a
特定的市场需要它,或者因为供应商认为
它增强了产品,而另一个供应商可能会省略相同的项目。
不包含特定选项的实现必须是
准备与另一个实现进行互操作
包括这个选项,虽然也许function减less了。 同样的一个实现包括一个特定的选项
必须准备与另一个实现进行互操作
不包括这个选项(当然除了这个function的
选项提供)。

总而言之,根可能在服务器握手阶段提供的authenticationpath上。

实际使用。
考虑一下,不是用导航用户的话来说,而是用在互联网接入有限的军事领域的服务器上的转移工具。
在传输中扮演客户端angular色的服务器接收来自服务器的所有证书path。
链中的所有证书都应该被检查为可信,包括根。
唯一的方法来检查这是在传输时间的根目录被包括在证书path,匹配以前宣布为“可信”的本地副本。

当您看到“ Verify return code: 19 (self signed certificate in certificate chain) ”时,则服务器确实试图使用自签名证书(客户端永远无法validation)或OpenSSL没有访问必要的根,但服务器试图提供它本身(它不应该这样做,因为它是毫无意义的 – 客户永远不能相信服务器提供与服务器自己的证书相对应的根)。

再次,添加-showcerts将帮助您诊断哪个。