11

I am trying to yield a certificate verification error with openssl s_client like this:

$ openssl s_client -crlf -verify 9 \ -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \ -starttls smtp -host mx-ha03.web.de -port 25

The certificate of the web.de server is certified by the Deutsche Telekom CA, not TURKTRUST, thus the above command should fail, right?

But it reports:

 Verify return code: 0 (ok)

Why?

I mean an analog gnutls-cli command fails as expected:

$ { echo -e 'ehlo example.org\nstarttls' ; sleep 1 } | \ gnutls-cli --starttls --crlf \ --x509cafile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \ --port 25 mx-ha03.web.de [..] *** Verifying server certificate failed...

Doing a crosscheck, i.e. using instead --x509cafile /etc/ssl/certs/ca-certificates.crt with gnutls-cli I get:

[..] - The hostname in the certificate matches 'mx-ha03.web.de'. - Peer's certificate is trusted

(which is also expected)

Openssl s_client prints for ca-certificates.crt:

 Verify return code: 0 (ok)

The same result as for TURKTRUST ...

First I suspected openssl using a default setting for -CApath (i.e. /etc/ssl/certs) - but when I strace the process I just see just the open syscall for the argument of CAfile.

(all tests done on a Ubuntu 10.04 server)

Update: I've copied the TURKTRUST certificate to a Fedora 20 system and executed the first openssl statement - there I get a different result:

Verify return code: 19 (self signed certificate in certificate chain)
Improve this question

1 Answer 1

Reset to default
11

It turns out that the openssl s_client on Ubuntu 10.04 still queries a default location for system installed certificates, even if -CApath and -CAfile are specified:

8466 open("/usr/lib/ssl/certs/4e18c148.0", O_RDONLY) = 4

(strace output)

Where:

$ ls -l /usr/lib/ssl/certs/4e18c148.0 lrwxrwxrwx 1 root root 30 2014-04-11 21:50 /usr/lib/ssl/certs/4e18c148.0 -> Deutsche_Telekom_Root_CA_2.pem

The directory /usr/lib/ssl/certs is a symlink to /etc/ssl/certs on Ubuntu 10.04, thus the open line from the strace log is not selected when grepping for '/etc/ssl' ...

Source

Looking at the openssl-0.9.8k, the source of this issue is located in crypto/x509/by_dir.c, dir_ctrl():

dir=(char *)Getenv(X509_get_default_cert_dir_env()); if (dir) ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM); else ret=add_cert_dir(ld,X509_get_default_cert_dir(), X509_FILETYPE_PEM);

Where X509_get_default_cert_dir returns /usr/lib/ssl/certs and X509_get_default_cert_dir_env returns SSL_CERT_DIR.

Workaround

Thus, one can use following workaround under Ubuntu 10.04/openssl 0.9.8k to get the expected behavior:

$ SSL_CERT_DIR="" openssl s_client -crlf -verify 9 \ -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.crt \ -starttls smtp -host mx-ha03.web.de -port 25

And with the verification fails:

Verify return code: 19 (self signed certificate in certificate chain)

Current Situation

This is a Ubuntu issue. For example, with the Fedora 20's openssl 1.0.1e or Fedora 29's openssl 1.1.1, this workaround is not necessary, because the issue cannot be reproduced. That means when specifying an option like -CAfile or -CApath, no default certificate system directory is added to the directory search list on Fedora systems.

On Ubuntu 16 with openssl 1.0.2g the issue is still present.

It's also present on CentOS 7 with openssl-1.0.2k-16 - and unfortunately, the above workaround doesn't help there and the gnutls-3.3.29-8 fails due to unknown/unexpected TLS packet types.

Improve this answer
4
  • 1
    I have version 1.0.2g and it still has this bug. To make things worse, the -verify_return_error flag has no effect whatsoever and the TLS connection proceeds even if the cert is wrong. Commented Jan 15, 2019 at 9:31
  • @takumar, I re-tested this under Ubuntu 16 with openssl 1.0.2g-1ubuntu4.14 and I can confirm, without the workaround this openssl test still fails. But at least with the workaround I get the expected error message - and with the workaround and -verify_return_error the command terminates with exit status 1. With Fedora 29 and openssl-1.1.1-3.fc29.x86_64 everything still works as expected, i.e. the workaround isn't necessary. Commented Jan 15, 2019 at 10:14
  • In 2019, this still seems to be the case on macOS. Also, some systems might support -no-CAfile (Do not load the trusted CA certificates from the default file location) and -no-CApath (Do not load the trusted CA certificates from the default directory location), but my system does not, so I've not tested those. Commented May 2, 2019 at 13:01
  • @takumar it seems that you can get -verify_return_error to work if you also specify -verify <depth> - the manpage says about -verify: "This specifies the maximum length of the server certificate chain and turns on server certificate verification. Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure." Commented Dec 31, 2020 at 8:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.