OpenSSL无法在certs文件夹中提取CA

我们curl无法连接到HTTPS服务器遇到了麻烦：

$ curl https://the-problem-site.com    (not the real URL!)   
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

1112 SSL_R_TLSV1_UNRECOGNIZED_NAME在ssl.h。

如果我试试看，openssl s_client -connect the-problem-site.com:443我会看到

CONNECTED(00000003)   
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
verify error:num=20:unable to get local issuer certificate   
verify return:0   

Certificate chain   
0 s:/serialNumber=xx/C=xx/ST=xx/L=xxxx/O=xx/OU=xx/CN=the-problem-site.com   
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA   

即看起来问题是它不信任/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA。但是安装了该证书：是/etc/ssl/certs/GeoTrust_Global_CA.pem，如果我运行

openssl s_client-连接-problem-site.com:443 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem

然后一切正常。证书也以哈希文件形式存在，位于b0f3e76e.0中ca-certificates.crt。但是，据我所知，curl和openssl都没有尝试读取任何证书。如果我是strace他们，那么即使有错误，也不会尝试读取/usr/lib/ssl/certs或根本不会读取/etc/ssl/certs。它确实读取了openssl.cnf。我们已经跑了update-ca-certificates。

这是Ubuntu 10.04，带有openssl 0.9.8k。我们可以在两个单独的安装中重现该问题（尽管有可能一个人从另一个安装中复制了一个）。如果我在带有openssl 0.9.8e的CentOS VM上尝试相同的测试，那么它可以正常工作，并且可以看到它读取了证书文件strace。在Ubuntu strace中，没有相同的文件访问权限。如果我将openssl.cnf文件从CentOS VM 复制到Ubuntu计算机，则没有任何区别。没有明显的环境或.rc文件可能会导致这种情况。

有什么想法我做错了吗？这应该工作吗，即openssl和curl是否应该从命令行自动获取已安装的CA？如何配置？谢谢！

另一个数据点：在13个服务器的全新安装上，curl确实提取了证书文件并正常工作。openssl s_client仍然没有。为什么会这样呢？

您的系统上有几个密码库：

• OpenSSL（黄金标准，具有BSD风格（非常免费）的许可证，其中包括一些有问题的条款（防止GPL兼容性，但没有“不好”的字样）限制了它在GNU世界中的采用）
• GnuTLS（由FSF替代）；有两种版本：LGPLv2许可（但未维护）和LGPLv3许可（因此与仅GPLv2程序不兼容）；从历史上讲不像OpenSSL那样功能强大，但有很多错误，但是更加严格也可以提高安全性）
• NSS（Netscape / Mozilla的库，在外部很少使用；采用新标准的速度很慢）
• 次要的，例如PolarSSL，MatrixSSL，NaCl /盐

当然，它们所有人都有相同点和不同点。使用它们（用于加密目的或使用SSL / TLS）的软件有时支持使用其中一个以上的库（例如，Web浏览器Lynx）通常与OpenSSL链接，但在其中也支持GnuTLS（只是不那么好）为了安抚GNU人民）。

cURL也是支持使用三个主要加密库之一的项目之一。这主要是因为cURL主要是一个库，旨在供其他程序在使用http，ftp等连接下载（甚至上传）内容时使用。该curl命令行工具可以来自这些变种。

现在，我相当确定您在未全新安装的系统中遇到的问题如下：

OpenSSL和GnuTLS都支持使用/etc/ssl/certs/<hash>.<number>-style CA目录。但是，OpenSSL版本0.x和GnuTLS使用与OpenSSL版本1.x 不同的算法来计算上述哈希。（两者都可以在系统上共存；如果不同的证书具有相同的哈希，则只对它们使用不同的数字。但是由于某些原因，Debian / Ubuntu的ca-certificates软件包似乎没有这样做。）此外，某些版本的GnuTLS并未这样做支持使用目录，但仅使用文件/etc/ssl/certs/ca-certificates.crt（通常也由ca-certificates软件包的维护者脚本管理，但可能会有所不同）；您似乎使用的是旧版本，所以这可能是您遇到的问题。

openssl s_client默认情况下（即不带-CApath或-CAfile选项）不会在任何地方查找证书。

curl升级安装中的您很可能使用curl与全新安装中不同的密码库。

openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443除了openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443模仿旧版GnuTLS的行为外，还请尝试。

仔细检查，如果有一个OpenSSL的1.x的任何地方你的系统（Ubuntu的是著名的潜入主要更新连入LTS版本），如果是，检查文件的哈希：

openssl x509 -noout -hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash_old -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem

通常，第二个和第三个命令应该失败（OpenSSL 0.x），或者第一个和第三个命令应该显示相同的哈希，但是第二个命令应该显示不同的哈希（OpenSSL 1.x）。GnuTLS将使用第二个命令的输出（如果已安装OpenSSL 1.x）；如果安装的OpenSSL 0.x是相同的哈希值。您可以手动创建此类符号链接。

提供调试反馈后，我可以更新此帖子。