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)
Best Answer
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:(strace output)
Where:
The directory
/usr/lib/ssl/certs
is a symlink to/etc/ssl/certs
on Ubuntu 10.04, thus theopen
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()
:Where
X509_get_default_cert_dir
returns/usr/lib/ssl/certs
andX509_get_default_cert_dir_env
returnsSSL_CERT_DIR
.Workaround
Thus, one can use following workaround under Ubuntu 10.04/openssl 0.9.8k to get the expected behavior:
And with the verification fails:
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.