<div dir="ltr">tl;dr: Found an issue with update-ca-trust extract<div>OpenSSL doing what it should, but update-ca-trust is only pushing the cert into some of the trust stores.</div><div><br></div><div>Thanks Tomas<br><br>On Tue, 29 Sep 2020 at 07:06, Tomas Mraz <<a href="mailto:tmraz@redhat.com" target="_blank">tmraz@redhat.com</a>> wrote:<br>><br>> On Mon, 2020-09-28 at 22:35 +0100, John Robson via openssl-users wrote:<br>> > Hi,<br>> ><br>> > I'm really struggling to get my head around a specific scenario that<br>> > isn't behaving as I expect.  Hopefully someone with more<br>> > experience/knowledge can set me on the right path.<br>> ><br>> > Note - my attempts to reproduce this in a lab have been unsuccessful,<br>> > although I don't have access to the server private key, so the<br>> > attempts have been with a completely independent CA chain.<br>> ><br>> ><br>> > I have a private CA, which has signed an intermediate certificate<br>> > which has signed a server certificate for an internal web server<br>> > which is used by various automated systems (all linux based).<br>> ><br>> > The webserver (Apache) has the server cert and key, defined and in<br>> > use as well as the intermediate certificate defined as the chain<br>> > certificate - this all shows as expected.<br>> ><br>> > I have then added the root certificate to the trusted certs for an<br>> > automated system (populated `/etc/pki/ca-trust/source/anchors/` run<br>> > `update-ca-trust extract`).<br>> ><br>> > After this curl no longer complains about the certificate from the<br>> > web server (expected).<br>> > However OpenSSL still does (unexpected), and I presume that for the<br>> > same reason(s) urllib in Python also doesn't accept the certificate.<br>> > If I manually feed `openssl verify` the certificates and chain then<br>> > they all come back "OK".<br>> ><br>> > I've set up these systems a number of times with both self signed and<br>> > CA signed certs and never seen this behaviour.<br>><br>> ...<br>> ><br>> > OpenSSL:<br>> > # openssl s_client -connect server.fqdn:443<br>> > CONNECTED(00000007)<br>> > depth=1 CN = CAINTER, O = org, C = XX<br>> > verify error:num=2:unable to get issuer certificate<br>> > issuer= CN = CAROOT, O = org, C = XX<br>> >  --8<--<br>> > Verify return code: 2 (unable to get issuer certificate)<br><br><br>> What is the curl library linked to? Is it using OpenSSL or something<br>> else, for example NSS, as the TLS library? What exact system are you<br>> testing on?<br><br>Running curl -v on a lab box it shows that curl is using NSS, which at least gives some reason for the different behaviour.<br>The system is a dockerised monitoring utility (clue is in the email address) with the containers based on CentOS.<br> <br>> Are you sure you've put your CAROOT certificate to the system<br>> certificate trust store? And/or is the trust store properly set up to<br>> be loaded by OpenSSL by default?<br><br>Curl complains about the certificate until I add the cert to the ca-trust, so I have a good degree of confidence that the cert has been installed into the trust store - and on all the systems I've installed thus far this has also been picked up by OpenSSL.<br><br>openssl connect does negotiate a key and cipher, and there is a connection created, so I'm confident there isn't a key/cipher capability mismatch, it's just the certificate verification that is failing.<br><br>Checking where OpenSSL is using for it's CA trust store:<br># openssl version -d<br>OPENSSLDIR: "/etc/pki/tls"<br><br>In that directory cert.pem is a symlink to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, which is subtly different from the /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt I had been searching earlier - however I still see the ROOTCA entry in the pem bundle (and they have identical timestamps, indicating that both were updated by the update-ca-trust extract command).<br><br>I'm getting a closer look at those files to make sure that the cert has been correctly pushed into them. I can't imagine why it wouldn't have been, but it is the next logical thing to check.<br><br><div>OK - The issue is that update-ca-trust extract command i was using doesn't do what I would expect from the docs (and previous experience)</div></div><div><br></div><div>Even with the Root CA in the anchors directory it doesn't add it to the TLS ca store, it does add it elsewhere though.</div><div>If I manually add it to the ca-bundle.trust.crt then OpenSSL does verify the cert correctly, but the cert gets pulled if I then run the update again, so that's not a good long term solution.</div><div><br></div><div>Since I have the Root CA I can test adding it to a few different containers and see whether there is something about that cert that is causing the odd behaviour.</div><div><br></div><div>Thanks to Tomas for reminding me there are various different cert trust stores, and for ensuring that I followed the correct path deep enough to figure out what was going on.</div><div><br></div><div>Now to try and work out ca-certificate behaviour,</div><div><br></div><div>Cheers,</div><div><br></div><div>John</div><div><br></div></div>