SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate )

Alex Robuchon alexandre.robuchon at
Sat Oct 2 15:24:26 UTC 2021

Hello Openssl community,

I've encountered an issue with em-http-request ( based on top of eventmachine ( since let's encrypt Root
certificate expired the 30th of September. The project has a callback
function registered with SSL_CTX_set_verify and failed to verify DST Root
CA X3 since it expired.

>From what I understood about the let's encrypt certificate chain, R3 is
cross signed and two chained could be built:

   - leaf <- R3 <- ISRG Root X1 <- DST Root CA X3 (self-signed)
   - leaf <- R3 <- ISRG Root X1 (self-signed)

The servers by default return the first chain but from what I understand
depending on the openssl version/flags it should  use the second path if ISRG
Root X1 is in the store

My config :
openssl version : OpenSSL 1.1.1f  31 Mar 2020
os : 5.8.0-63-generic #71-Ubuntu SMP Tue Jul 13 15:59:12 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
ISRG Root X1 self signed is in my cert store.

So from what I understand, trusted first is default in this version of
openssl and the second path should be taken.

For the record s_client can valide the second path on my machine :
$ echo | openssl s_client -connect -name
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN =
verify return:1
Certificate chain
0 s:CN =
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3

So I suppose the problem relies on the use of openssl in the ruby libs.
However what I'm a bit surprised with is the fact that SSL_CTX_set_verify
is called with the "wrong" certificate chain. The documentation says it's
going to be called for each certificate in the chain but do not specify if
it's the chain specified by the server or the one built by openssl with
trusted first algorithm.

I also tried adding a verify callback on the ruby net http library ( which is passed to SSL_CTX_set_verify
under the hood and I also noticed that it's using the "wrong" chain.

Is it normal to have the callback defined in SSL_CTX_set_verify to be
called with the wrong chain ? Or do you think something is not configured
correctly on these gems ?

If it's normal behavior how can I have additional certificate verification
on the trusted first chain.

Thanks for reading,  I hope it was not too boring or confusing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openssl-users mailing list