9

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?

3
  • We are experiencing exactly the same issue. I'm sensing some dodginess in openssl! Sep 25, 2013 at 19:35
  • @Rup Have you found a solution to this? Please add and mark an answer if so. We are seeing this same behavior.
    – Mike S
    Oct 15, 2013 at 20:34
  • @MikeS Not as far as I know sorry, but I'm not on that team. I'll ask them tomorrow.
    – Rup
    Oct 15, 2013 at 21:03

1 Answer 1

5

There are several cryptographic libraries on your system:

  • OpenSSL (the gold standard, with a BSD-style (very free) licence that includes a somewhat problematic clause (preventing GPL compatibility, but nothing “bad”) limiting its adoption in the GNU world)
  • GnuTLS (the replacement from the FSF; comes in two flavours, LGPLv2-licenced (but unmaintained) and LGPLv3-licenced (and thus incompatible with GPLv2-only programs); historically not as featureful as OpenSSL, a bit more buggy, but more strict too, which enhances security)
  • NSS (Netscape/Mozilla's library, rarely used outside; slow to adopt new standards)
  • minor ones like PolarSSL, MatrixSSL, NaCl/Salt

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's ca-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 the ca-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 the curl from the fresh installation.

Try openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443 in addition to openssl 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:

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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .