背景:
- aws.amazon.com/ec2 上的 Ubuntu Server 14.10 64 位
- 来自 COMODO 的廉价 PositiveSSL 服务器证书
- 1 个服务器证书、2 个中级 CA 证书和 1 个根 CA 证书(以 COMODO 的 ZIP 存档形式提供)
- Citadel 的 WebCit httpsd
问题:
连接的证书链似乎正确,但验证失败。
openssl s_client myhost:port
显示证书链,并且颁发者-主题对在链中正确排列,但是:
verify error:num=19:self signed certificate in certificate chain
尽管默认情况下在 Ubuntu 服务器信任库中可以找到根 CA 证书,但 openssl 并不接受该证书。
具体来说:
AddTrustExternalCARoot.crt
收到来自 COMODO 的每封电子邮件,并且
/etc/ssl/certs/AddTrust_External_Root.pem
其链接
/usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt
相同。
这里有什么问题?
答案1
OpenSSL 至少到当前版本(1.0.2a)有一个漏洞s_client
没有-CA{path,file}
参数的地方实际上没有使用默认信任库应该如此,因此无法验证根据该信任库有效的证书。(还有s_server
和s_time
,但很少关心这些证书的验证。)请参阅https://serverfault.com/questions/607233/how-to-make-openssl-s-client-using-default-ca。已在开发中宣布修复,但可能需要一些时间才能发布和分发。在此期间,您需要明确指定参数-CA*
。请注意,openssl verify
没有此错误,因此正确地将证书/链报告为有效。
更新2015/08/26:修复已发布2015/06/12 1.0.1o 和 1.0.2c。此外,在调查其他内容时,我发现RedHat 软件包可能还不错. 更具体地说,据我所知,CentOS 源 RPMopenssl-1.0.1e-30.el6.11
是 RedHat 源 RPM 的副本(但无法轻易确认),openssl-1.0.1c-default-paths.patch
其中包含对 2012/12/06 的更改s_client.c s_server.c s_time.c
,这些更改似乎等同于(尽管在文本上并不相同)2015/06/12 上游修复。假设此补丁已应用于 RedHat 和 CentOS 软件包,我无法轻易返回并检查,它们将(已经)按预期工作。
答案2
最近,在使用 Ruby 开发脚本时,我遇到了与 Comodo 证书类似的问题。最终,OpenSSL 存储中没有该证书,尽管它看起来有。
为了测试这一点,请下载所有 Comodo 中级证书并创建类似这样的证书包(您需要根据下载的内容使用不同的证书名称):
cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle
完成后,尝试使用 OpenSSL 再次验证证书并在命令行上指定证书存储:
openssl verify -untrusted yourDomain.ca-bundle cert.pem
该示例改编自这篇 Unix 和 Linux StackExchange 文章。
一旦确定了证书类型,就可以将该证书添加到本地证书存储区,Ubuntu 版本的详细信息请见此处,类似于:
在 /usr/share/ca-certificates 中为额外的 CA 证书创建目录
sudo mkdir /usr/share/ca-certificates/extra
将“.crt”文件复制到目录
sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt
让 Ubuntu 将 '.crt' 文件相对于 /usr/share/ca-certificates 的路径添加到 /etc/ca-certificates.conf
sudo dpkg-reconfigure ca-certificates
答案3
comodo 根证书不再受信任 - 如果您不知道原因,请在 Google 上搜索“comodo 被盗证书”。
尽管 comodo 证书可能很便宜,但其价值却远低于其价格:它实际上毫无价值,信任链被打破了。