91

I have an end-entity/server certificate which have an intermediate and root certificate. When I cat on the end-entity certificate, I see only a single BEGIN and END tag. It is the only the end-entity certificate.

Is there any way I can view the intermediate and root certificate content. I need only the content of BEGIN and END tag.

In Windows I can see the full cert chain from the "Certification Path". Below is the example for the Stack Exchange's certificate.

enter image description here

From there I can perform a View Certificate and export them. I can do that for both root and intermediate in Windows. I am looking for this same method in Linux.

enter image description here

2
  • 1
    Please do tell us who issued you that cert. May 30, 2017 at 15:15
  • @RuiFRibeiro Let's say anyone... I want to see the cert chain for stackexchange with only the primary certificate in hand. May 30, 2017 at 15:57

5 Answers 5

85

From a web site, you can do:

openssl s_client -showcerts -verify 5 -connect stackexchange.com:443 < /dev/null

That will show the certificate chain and all the certificates the server presented.

Now, if I save those two certificates to files, I can use openssl verify:

$ openssl verify -show_chain -untrusted dc-sha2.crt se.crt 
se.crt: OK
Chain:
depth=0: C = US, ST = NY, L = New York, O = "Stack Exchange, Inc.", CN = *.stackexchange.com (untrusted)
depth=1: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA (untrusted)
depth=2: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA

The -untrusted option is used to give the intermediate certificate(s); se.crt is the certificate to verify. The depth=2 result came from the system trusted CA store.

If you don't have the intermediate certificate(s), you can't perform the verify. That's just how X.509 works.

Depending on the certificate, it may contain a URI to get the intermediate from. As an example, openssl x509 -in se.crt -noout -text contains:

        Authority Information Access: 
            OCSP - URI:http://ocsp.digicert.com
            CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt

That "CA Issuers" URI points to the intermediate cert (in DER format, so you need to use openssl x509 -inform der -in DigiCertSHA2HighAssuranceServerCA.crt -out DigiCertSHA2HighAssuranceServerCA.pem to convert it for further use by OpenSSL).

If you run openssl x509 -in /tmp/DigiCertSHA2HighAssuranceServerCA.pem -noout -issuer_hash you get 244b5494, which you can look for in the system root CA store at /etc/ssl/certs/244b5494.0 (just append .0 to the name).

I don't think there is a nice, easy OpenSSL command to do all that for you.

10
69

tl;dr - one liner bash magic to dump all certs in the chain

openssl s_client -showcerts -verify 5 -connect wikipedia.org:443 < /dev/null |
   awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){a++}; out="cert"a".pem"; print >out}'
for cert in *.pem; do 
        newname=$(openssl x509 -noout -subject -in $cert | sed -nE 's/.*CN ?= ?(.*)/\1/; s/[ ,.*]/_/g; s/__/_/g; s/_-_/-/; s/^_//g;p' | tr '[:upper:]' '[:lower:]').pem
        echo "${newname}"; mv "${cert}" "${newname}" 
done

Explanation in 2 steps

To dump all certs in the chain to the current dir as cert${chain_number}.pem:

openssl s_client -showcerts -verify 5 -connect your_host:443 < /dev/null |
 awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){a++}; out="cert"a".pem"; print >out}' 

The bonus-track to rename them to their common name:

for cert in *.pem; do 
   newname=$(openssl x509 -noout -subject -in $cert | sed -nE 's/.*CN ?= ?(.*)/\1/; s/[ ,.*]/_/g; s/__/_/g; s/_-_/-/; s/^_//g;p' | tr '[:upper:]' '[:lower:]').pem
   mv $cert $newname 
done
12
  • Is there any reason to choose ".pem" versus ".crt" as the extension since you're only renaming them, not changing the format? Feb 5, 2019 at 21:23
  • 3
    No, not really. ".pem" is the format (base64 of the DER) ".crt" means it's a certificate but doesn't tell anything about the encoding. I was about to make it more consistent and name all pem... But I think is simpler to read in the one liner to understand where the certificate is getting downloaded (crt) and finish what I typically use in the Linux world (pem). Hope this clarifies things a bit...
    – estani
    Feb 6, 2019 at 23:16
  • 1
    Yes it does, I realize PEM is a format but I often see crt and wasn't sure if it was a format. This actually helps explain why I see "crt" used so often. Thanks :) Feb 7, 2019 at 16:59
  • This seems to only work if you already trust the source. I'm trying to download a custom CA but it's only downloading the first certificate, not the chain.
    – mjaggard
    Jul 5, 2019 at 8:37
  • 1
    @kensai as previously mentioned, that should not be the case. The server might not be sending it though, as it makes little sense. See RFC 5246 - TLS v1.2, sec. 7.4.2. - Server Certificate
    – estani
    Sep 11 at 12:34
7

I found out that with the option -verify 5 openssl is going deep in the chain showing all the cert, even that not included in your certificate deployment.

If you really want to understand which chain is provided with your certificate you should run:

openssl s_client -showcerts -partial_chain -connect YOUR_ENDPOINT:443 < /dev/null |less
1
  • unknown option -partial_chain
    – jobwat
    Nov 28, 2022 at 4:45
2

The above failed to work for me when I was using a Lets Encrypt Free Wildcard Certificate.

To be more specific:
I have a Kubernetes Cluster + Ingress Controller that's configured using a Lets Encrypt Free Wildcard Certificate for *.mydomain.dev, it's hosting the following 2 domain names:

  • grafana.mydomain.dev
  • prometheus.mydomain.dev

I had to add the -servername flag following per this site: https://community.letsencrypt.org/t/where-can-i-download-the-trusted-root-ca-certificates-for-lets-encrypt/33241/2

export DOMAIN=grafana.mydomain.dev
openssl s_client -showcerts -verify 5 -connect $DOMAIN:443 -servername $DOMAIN < /dev/null 2> /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; print}'

I also tweaked the chain so it gives me the full cert + intermediate + root to standard output & hide stderr noise.

Actually... When testing I found out this doesn't give me the CA... openssl s_client -showcerts -verify 5 -connect letsencrypt.org:443 < /dev/null 2> /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; print}'

curl https://letsencrypt.org/certs/isrgrootx1.pem Gives a different value (and when testing some stuff this is the value that works.)

2

I also had the same challenge and next to that I discovered that openssl doesn't return the root ca. I have built an alternative for specifically for this purpose which might be useful for other developers, see here: GitHub - Certificate ripper

Usage

  • Printing to the console
crip print --url=https://stackexchange.com --format=pem
  • Exporting to a p12 trustore
crip export pkcs12 --url=https://stackexchange.com

The pkcs12 option can be replaced for pem or der if you want a different output.

1
  • 1
    yes agreed I tried other answers but they didn't return root certificate Feb 6 at 12:03

You must log in to answer this question.

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