+++ This bug was initially created as a clone of Bug #418771 +++ Description of problem: it seems that when I use "openssl s_client -connect ..." I need to explicitly specify "-CAfile /etc/pki/tls/certs/ca-bundle.crt" I was expecting that one to be used by default, but maybe my expectations are just wrong Version-Release number of selected component (if applicable): openssl-0.9.8b-17.fc8 How reproducible: always Steps to Reproduce: 1. use claws-mail 2. get a new certificate from your email server 3. be completely paranoid that a cert that claims to be signed by verisign fails verification with "unable to get local issuer certificate" 4. debug Actual results: it turns out that openssl s_client -connect mail.kolumbus.fi:993 will fail with the error above, while openssl s_client -CAfile /etc/pki/tls/certs/ca-bundle.crt -connect mail.kolumbus.fi:993 tells me "Verify return code: 0 (ok)" Expected results: I would expect not to have to manually specify the system-wide default ca-bundle, and it seems claws-email has the same expectations. Additional info: -- Additional comment from tmraz on 2007-12-12 14:09 EST -- The openssl s_client case is a bug in openssl - note that openssl s_client -CApath whatevernonexistent -connect .... will work fine. But I have looked at the claws-mail sources and this bug doesn't apply there and it apparently does some certificate chain verification on its own so this bug should be cloned for claws-mail if you want to have it fixed there too.
IRC discussion I had about this last week: <pcfe_laptop> hello. ssl cert question (and do feel free to point me at the relevant docs, my hunt through docs came up empty but I may very well have missed it) <pcfe_laptop> does claws use the system-wide ca-bundle to check it's certs? In my openssl-0.9.8b-17.fc8 that would be /etc/pki/tls/certs/ca-bundle.crt <-- TuxCM- has quit (Read error: 110 (Connection timed out)) <pcfe_laptop> because if it does then I need to nag at my provider as I get presented a cert that claims to be signed by verisign but claws says that it is 'unable to get local issuer certificate' which I understand as it being unable to verify the cert. <colinl> pcfe_laptop: which claws version? <pcfe_laptop> colinl: Claws Mail version 3.1.0 <colinl> compiled against openssl or gnutls? <pcfe_laptop> colinl: mompls, let me grab the srpm and check <pcfe_laptop> BuildRequires: openssl-devel >= 0.9.7 <pcfe_laptop> %configure --enable-openssl --enable-ipv6 \ <pcfe_laptop> --enable-ldap --enable-jpilot \ <pcfe_laptop> --enable-spamassassin-plugin \ <pcfe_laptop> --enable-aspell \ <pcfe_laptop> --disable-dependency-tracking \ <pcfe_laptop> --disable-rpath \ <pcfe_laptop> --enable-compface <pcfe_laptop> colinl: so it would seem against openssl <colinl> ok <colinl> so it's proablby not claws' fault <colinl> try with openssl: <colinl> openssl s_client -connect colino.net:995 <colinl> (replace colino.net:995 with the host:port of your ISP's mail host) <pcfe_laptop> colinl: you are right, it is not claws' fault; Verify return code: 20 (unable to get local issuer certificate) <colinl> ok :) <pcfe_laptop> and I guess this is the problem: No client certificate CA names sent <pcfe_laptop> colinl: hmm, this works <pcfe_laptop> openssl s_client -CAfile /etc/pki/tls/certs/ca-bundle.crt -connect mail.kolumbus.fi:993 <pcfe_laptop> openssl oddity then, I'll take it up with the package maintainer <colinl> hmm, strange that openssl doesn't find them
>But I have looked at the claws-mail sources and this bug doesn't apply there and >it apparently does some certificate chain verification on its own so this bug >should be cloned for claws-mail if you want to have it fixed there too. Claws Mail does nothing on its own to check certificate chains. It just calls SSL_CTX_set_default_verify_paths(ssl_ctx); this uses X509_CERT_DIR and/or X509_CERT_FILE, which are defined in openssl as #define X509_CERT_DIR OPENSSLDIR "/certs" #define X509_CERT_FILE OPENSSLDIR "/cert.pem"
The CVS version of Claws Mail now checks for the existence of the following files: "/etc/pki/tls/certs/ca-bundle.crt", "/etc/certs/ca-bundle.crt", "/usr/share/ssl/certs/ca-bundle.crt", "/etc/ssl/certs/ca-certificates.crt", "/usr/local/ssl/certs/ca-bundle.crt", "/etc/apache/ssl.crt/ca-bundle.crt", "/usr/share/curl/curl-ca-bundle.crt", "/usr/share/curl/curl-ca-bundle.crt", "/usr/lib/ssl/cert.pem", It uses the first found, unless SSL_CERT_FILE is defined in the environment. If none is found, it now uses certificates found in the following directories: "/etc/pki/tls/certs", "/etc/certs", "/usr/share/ssl/certs", "/etc/ssl/certs", "/usr/local/ssl/certs", "/etc/apache/ssl.crt", "/usr/share/curl", "/usr/lib/ssl/certs", It uses the first found, unless SSL_CERT_DIR is defined in the environment. HTH