I download its certificates. To do that, I used the openssl debug output of the command

openssl s_client -connect security.stackexchange.com:443 -servername security.stackexchange.com -showcerts -debug </dev/null 2>&1|tee out

The output says nothing unusual, it is an ordinary ssl handshake, including the certificate chain. I do not post only because it is long (but is available if someone needs).

Then, I extract the certificates from the debug output with a well-done editor. There are 4 of them.

If I try to verify them with the openssl verify command, I get this:

$ openssl verify -CAfile s4.crt s3.crt
C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 1 depth lookup: unable to get issuer certificate
error s3.crt: verification failed


This site, the security.stackexchange.com, has a perfect okay cert chain, verification should work without any problem.

Note, I am trying to verify the penultimate cert of the chain (C = US, O = Internet Security Research Group, CN = ISRG Root X2) with the last (C = US, O = Internet Security Research Group, CN = ISRG Root X1) certificate. Intermediate certs should not play any role, making this question not a dupe of this.

1 Answer 1


Intermediate certs should not play any role,

They do. The last certificate sent by the server is an intermediate certificate:

Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3

But in order to use an intermediate certificate instead of a root certificate (self-signed, issuer and subject are the same) one need to use the -partial_chain option for openssl verify. And this is true when validating the other steps of chain.

  • King. I see a king.
    – peterh
    Jan 10 at 9:14
  • And of course with -partial_chain it treats E1 (or R1) as the anchor and doesn't verify anything beyond the leaf. But did you actually get a chain ending in X2-X1? I don't, nor does ssllabs, from and . Both of us (still, for a few more months) get the X1-DSTX3 bridge, which is also an intermediate, and I think the OpenSSL code (X509_cert_verify) should find that (and then fail on DSTX3 root, of course, because it isn't sent and has been removed from most truststores even if a default CApath was/is used and is expired). Will debug later if I have time. Jan 11 at 7:09
  • @dave_thompson_085: you are right , the last chain certificate was X3-X1. I've fixed this in the answer. This does not change the answer otherwise though, since the server does not send a root certificate (and should not). Jan 11 at 9:36

You must log in to answer this question.

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