So I look after 2 web servers, one old, one new. The old one uses our old url, the new, our new url, both are internally signed.

The HTTPS certificate is about to expire on the old one, so I've checked and even though it has 1 month left on it, it's identifying as not valid, due to it's certificate authority, which is an internal machine.
However, the new server, which has a similarly internally signed certificate is showing as valid, albeit it is signed by a different internal authority.

I'm struggling to figure out why the new cert is fine, but the old one is not. Either the new cert has some magic in it I'm not aware of (like the ultimate parent in the signing chain is one of the well known certs in my CA, but its not showing up when I interrogate the .crt), or the unfamiliar (internal) parent .crt in the signing chain, has been added to the ca-certificates on my ubuntu client.

What are the cli commands on my ubuntu desktop, or the centos client, that I can use to find out? If the reason why the new .crt works, is because of a certificate that's been installed on my desktop, how do I find where that certificate is installed (and how do I copy it on to other centos machines)?

I've tried openssl s_client -connect -showcerts to identify the chain on both servers and they end up with a signing authority CN that is internal. I've downloaded the certs and run openssl verify -verbose -issuer_checks and I don't see any parent authority that I'd recognise. I ran the same things on www.google.com and I get a familiar parent of 'GeoTrust Global CA', so I'm leaning towards the internal parent authority having been added to my local ca-certificates, but how can I check?

The CN which is reporting as the ultimate authority in all cases isn't a DNS name, so I can't download that .crt from somewhere, all I've got is what's in the new url .crt, so can I use openssl to lookup the certificate, from just a CN (which presumably openssl is doing internally to conclude it's valid, if the apparent parent .crt isn't in my local ca-certificates)?

Edit: I think the master key has been added to my chrome (libnss3) certificates. What is needed to add the same master key so it's supported by something other than chrome (like php and openssl on cli)

2 Answers 2


If anyone can come up with a better answer, please do, but the best I found was this:- http://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html

I found on my ubuntu desktop that /usr/share/ca-certificates is the primary location for certificates, but the one I was looking for was in /usr/local/share/ca-certificates. I found it by using find -iname "*<NAME>*" and searching for a name that matched the parent hostname in my key chain.

I also found that whilst Chrome on my desktop recognised the cert as valid, some cli tools (including openssl) didn't. Hence I found a reference in our docs to this command to add to libnss which apparently is what chrome uses as ca authority

certutil -d sql:${HOME}/.pki/nssdb/ -A -t "C,," \
         -n "<CERTIFICATE NAME>" \
         -i /usr/local/share/ca-certificates/<CERTIFICATE>.crt

The above link to gfi included some really useful stuff about managing ca-certs on ubuntu/centos. This is the stuff I cribbed for our own internal wiki:-

Linux (Ubuntu, Debian)


  1. Copy your CA to dir /usr/local/share/ca-certificates/
  2. Use command: sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
  3. Update the CA store: sudo update-ca-certificates


  1. Remove your CA.
  2. Update the CA store: sudo update-ca-certificates --fresh

Linux (CentOs 6)


  1. Install the ca-certificates package: yum install ca-certificates
  2. Enable the dynamic CA configuration feature: update-ca-trust force-enable
  3. Add it as a new file to /etc/pki/ca-trust/source/anchors/: cp foo.crt /etc/pki/ca-trust/source/anchors/
  4. Use command: update-ca-trust extract

Hope that saves someone the time I had to spend looking stuff up.


strace can help you figure out where openssl finds the trusted CA cert which ultimately validates the server cert:

$ strace -fe open,openat openssl s_client -connect www.google.com:443 > /dev/null
openat(AT_FDCWD, "/usr/lib/ssl/certs/1001acf7.0", O_RDONLY) = 4
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = www.google.com
verify return:1
+++ exited with 0 +++
$ openssl x509 -noout -subject < /usr/lib/ssl/certs/1001acf7.0
subject=C = US, O = Google Trust Services LLC, CN = GTS Root R1
$ ls -l /usr/lib/ssl/certs/1001acf7.0
lrwxrwxrwx 1 root root 15 Oct 30  2020 /usr/lib/ssl/certs/1001acf7.0 -> GTS_Root_R1.pem
$ dpkg -S /usr/lib/ssl/certs/1001acf7.0(:P)
ca-certificates: /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt

Above, that's /usr/lib/ssl/certs/1001acf7.0 where 1001acf7 is a hash of the subject of that certificate, here part of the system's standard root CA list ((:P) zsh glob qualifier to get the canonical absolute path).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .