We're having trouble with curl
not connecting to an HTTPS server:
$ curl https://the-problem-site.com (not the real URL!)
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
1112 is SSL_R_TLSV1_UNRECOGNIZED_NAME
in ssl.h
.
If I try openssl s_client -connect the-problem-site.com:443
instead then I see
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
i.e. it looks like the problem is that it doesn't trust /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
. However that cert is installed: it's /etc/ssl/certs/GeoTrust_Global_CA.pem
, and if instead I run
openssl s_client -connect the-problem-site.com:443 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem
then everything works. The cert is also present as a hash-named file b0f3e76e.0
and it's in ca-certificates.crt
. However, as far as I can see, neither curl nor openssl are attempting to read any certificates; if I strace
them then there's no attempt to read from /usr/lib/ssl/certs
or /etc/ssl/certs
at all, not even with errors. It does read openssl.cnf though. We have run update-ca-certificates
.
This is Ubuntu 10.04 with openssl 0.9.8k. We can reproduce the problem on two separate installs (though it's possible one's a clone of the other from way back). If I try the same test on a CentOS VM with openssl 0.9.8e then it works fine, and I can see it reading the certificate file in strace
. There's no equivalent file access at the same point in the Ubuntu straces. If I copy the openssl.cnf
file from the CentOS VM to the Ubuntu machines it makes no difference. There's nothing obvious in the environment or an .rc file that might be causing this.
Any ideas what I'm doing wrong? Should this work, i.e. should openssl and curl pick up installed CAs automatically from the command-line? How is this configured? Thanks!
Another data point: on a clean install of 13 server, curl
does pick up the certificates file and work fine. openssl s_client
still does not, though. Why would that be?
Best Answer
There are several cryptographic libraries on your system:
All of them have, of course, similarities and differences. Software that uses them (for cryptographic purposes, or to use SSL/TLS) sometimes supports using more than one of these libraries (for example Lynx, the web browser, is normally linked against OpenSSL but supports GnuTLS too (just not as good) in order to appease the GNU people).
cURL also is one of the projects supporting using either of the three major crypto libraries. This is mostly because cURL is, primary, a library intended to be used by yet other programs when they want to download (or even upload) things using http, ftp, etc. connections. The
curl
command-line tool can come from either of these variants.Now, I'm fairly sure that the problem you're seeing with the not-freshly-installed system is the following:
OpenSSL and GnuTLS both support using
/etc/ssl/certs/<hash>.<number>
-style CA directories. OpenSSL version 0.x and GnuTLS however use a different algorithm to calculate the aforementioned hash than OpenSSL version 1.x uses. (Both can coëxist on a system; if different certificates have the same hash you just use a differing number for them. But for some reason, Debian/Ubuntu'sca-certificates
package doesn't seem to do this.) Additionally, some versions of GnuTLS did not support using the directory, but only using a file/etc/ssl/certs/ca-certificates.crt
(which is also usually managed by theca-certificates
package's maintainer scripts, but can deviate); you seem to be using an older version, so this may be the thing you hit.openssl s_client
by default (i.e. without the-CApath
or-CAfile
option) does not look anywhere for certificates.Your
curl
from the upgraded installation most likely uses a different crypto library than thecurl
from the fresh installation.Try
openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443
in addition toopenssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443
to mimic the behaviour of older GnuTLS versions.Double-check if there's an OpenSSL 1.x anywhere on your system (Ubuntu is known for sneaking major updates even into LTS versions), and if yes, check the hash of the file:
Normally, either, the second and third command should fail (OpenSSL 0.x), or the first and third command should display the same hash but the second one should display a different hash (OpenSSL 1.x). GnuTLS would use the output from the second command (if OpenSSL 1.x is installed); if OpenSSL 0.x is installed that's the same hash. You can create such symlinks manually.
I can update this posting once you provide debugging feedback.