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签名的，但一个是自签名的。
-
如果有人能解释这个自签名证书是如何出现在CA签名证书中的？
-
这是错误
19 (self signed certificate in certificate chain)良性？ 如果不是，可能是什么原因造成的？ -
客户端在可信存储区中拥有CA证书，但自签名证书没有任何内容。 你认为这可能导致问题？ 如果是，我如何：
- 如何摆脱链式证书中的自签名证书，只留下2个CA签名的证书链？
- 在客户端可信存储上添加这个自签名证书？
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将帮助您诊断哪个。
