2010-11-05 172 views
33

我遇到问题并尝试进行调试。我们购买了Verisign证书。当我们使用:SSL握手失败,带有 - verisign链证书 - 包含两个CA签名证书和一个自签名证书

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. 在客户端可信存储上添加此自签名证书?
+0

谢谢布雷特茨基。我会检查中级证书。我想添加更多信息:当客户端发送上述openssl命令时,“client hello”到达服务器,但我们从未在客户端收到“server hello”。如果缺少中间证书,您是否期望这种行为?设备是一个Windows移动设备,服务器是Apache Web服务器。 – curiousone 2010-11-05 04:10:13

+0

什么类型的服务器/设备是加载的证书? – Brettski 2010-11-05 04:11:47

+0

您可以通过OpenSSL从其他设备/计算机连接吗?哪个版本的Windows Mobile,我有Windows Mobile和安全证书的噩梦体验。 – Brettski 2010-11-05 04:17:13

回答

7

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

这可能是因为您没有在服务器上加载完整的证书链。有些企业不允许他们的计算机下载其他证书,导致无法完成SSL握手。

这里是中间链的一些信息:由CA颁发
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

Intermediate CA Certificates

+0

太棒了。真的很好的信息。非常感谢你。我会加一次我的评论(明天)我尝试这些事情,让你知道这确实是问题。 – curiousone 2010-11-05 04:20:34

64

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

虽然浏览器和一些工具被配置为在默认情况下在位置上查找可信CA证书(其中一些可能是自签名的),但据我所知openssl命令不是。因此,任何从其最终实体证书(服务器证书)到根CA证书(可能具有中间CA证书)呈现完整证书链的服务器将在链中具有自签名证书:根CA.

openssl s_client -connect myweb.com:443 -showcerts没有任何特别的理由相信Verisign的根CA证书,因为它是自签名的,你会得到“的证书链自签名证书”。

如果您的系统在默认情况下可信证书捆绑的位置(我想/etc/pki/tls/certs在RedHat/Fedora和/etc/ssl/certs在Ubuntu/Debian的),你可以配置OpenSSL的将它们作为信任锚,例如像这样:

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

-CApath对于OS X会是什么? – Jonathan 2012-02-01 21:00:13

+5

我不认为OSX默认有一个,因为它依赖于此Keychain。您可以进入钥匙串访问,选择“系统根目录”中的所有证书(除去划掉的那些证书),右键单击并将所有项目导出为PEM文件,然后使用'-CAfile'(而不是'-CApath ')指向那个文件。 – Bruno 2012-02-02 00:10:59

+0

很酷,非常感谢! – Jonathan 2012-02-02 19:02:30

1

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

同样,添加-showcerts将帮助您诊断哪个。

2

关于服务器可以提供给客户端的根证书与否,从RFC-5246“传输层安全(TLS)协议1.2版”的文档,它说提取:

certificate_list
This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to validate it in any case.

关于术语“五一”,从RFC-2119中提取“当前最佳实践”说:

5.MAY
This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)

总之,根可以是由服务器在握手提供的证书路径。

实际使用。
想一想,不是以导航用户的角度来考虑,而是考虑在互联网接入有限的军事化区域的服务器上的传输工具。
在传输中扮演客户端角色的服务器接收来自服务器的所有证书路径。
链中的所有证书应该被检查为可信,包括根。
检查此问题的唯一方法是在传输时将根包含在certs路径中,并与之前声明为“受信任”的本地副本进行匹配。