Why openssl s_client verifies a cert against a mismatching CAfile?

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)