0

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

Why?

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.

Improve this question

1 Answer 1

Reset to default
3

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.

Improve this answer
3
  • King. I see a king. Commented Jan 10, 2024 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 172.64.144.30 and 104.18.43.226 . 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. Commented Jan 11, 2024 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). Commented Jan 11, 2024 at 9:36

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.