openssl: verify error:num=20:unable to get local issuer certificate

[Oliver Schonrock]

I know this is a popular error, however, please bear with me, I am
reasonably confident I have covered the obvious (famous last words!).

This is how I produce this certificate chain validation error (the site
is important):

$ openssl s_client -connect api.textmarketer.co.uk:443 2>&1 | less
depth=2 C = US, O = "thawte, Inc.", OU = Certification Services
Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN =
thawte Primary Root CA
verify error:num=20:unable to get local issuer certificate

This is on a fully updated FreeBSD 10.1 machine with
OpenSSL 1.0.1l-freebsd 15 Jan 2015
using (i believe, see below) the crt bundle
/usr/local/share/certs/ca-root-nss.crt

from
$ pkg info | grep nss
ca_root_nss-3.20.1

So openssl does not recognise that Thawte root cert as locally trusted,
but above file definitely contains that cert. I know this because:

a) I have manually forced openssl to use that file (hopefully getting
around all the path issues that most similar reported problems seem to
boil down to). Like this

$ openssl s_client -CAfile /usr/local/share/certs/ca-root-nss.crt
-connect api.textmarketer.co.uk:443

same result

b) I also compared the cert file with a one of my FreeBSD 10.2 machines
(which is working fine), and it's the same apart from the version number
in the first line. I also scp'd the crt bundle over to the working 10.2
machine and forced openssl to use it with -CAfile..that works fine

So the bundle file is fine, openssl is using that file (-CAfile reports
errors if I make an intentional mistake with filename). leaves just 2
things that I can think of:

1. something wrong with that site's cert or the cert chain it presents
..I thought this was it, because other sites work. eg:
openssl s_client -CAfile /usr/local/share/certs/ca-root-nss.crt -connect
google.com:443 2>&1

depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1

but remember: this site's cert path validates as trusted from the 10.2
machine with the same cert file. Also https://www.ssllabs.com/ssltest/
report no chain issue etc...

2. there is something wrong with the openssl installation on that 10.1
machine.

I did upgrade this machine from 10.0 to 10.1 using freebsd-update on
October 16th 2015 (too late I know, could that be the issue?). I also
installed the recent updates for ntpd vulnerabilities etc. I did reboot
after those.

Suspiciously, that problematic 10.1 machine was validating that exact
cert path fine before the upgrade from 10.0. I know this because
userland applications, like curl, are being used regularly to connect to
that very site and I have logs to prove that it was working ...and now
doesn't. I have put a workaround in place to get curl to connect
untrusted, but that's not good, clearly. It also worries me what else is
not working, or not secure?

So I am fast running out of ideas of how to narrow this down further.
Help please?!

Oh, that machine is in production, reboots etc are commercially
possible, but to be avoided as much as I can.

Many thanks in advance.

Oliver



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20151129/a834e74c/attachment.bin>