<div dir="ltr"><div><span style="font-size:18.76px;font-family:Arial,sans-serif">Hello Openssl community,</span><br></div><div><font face="Arial, sans-serif"><span style="font-size:18.76px"><br>I've encountered an issue with em-http-request (</span></font><a href="https://github.com/igrigorik/em-http-request" target="_blank">https://github.com/igrigorik/em-http-request</a>) based on top of eventmachine (<a href="https://github.com/eventmachine/eventmachine" target="_blank">https://github.com/eventmachine/eventmachine</a>) 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 <span style="font-family:Arial,sans-serif;font-size:18.76px">DST Root CA X3 since it expired.</span><br><br>From what I understood about the let's encrypt certificate chain, R3 is cross signed and two chained could be built:</div><ul style="margin:1em 0px 1em 1.25em;padding:0px 0px 0px 1.25em;clear:both;font-family:Arial,sans-serif;font-size:18.76px"><li style="margin-left:15px">leaf <- R3 <- ISRG Root X1 <- DST Root CA X3 (self-signed)</li><li style="margin-left:15px">leaf <- R3 <- ISRG Root X1 (self-signed)</li></ul><div><font face="Arial, sans-serif"><span style="font-size:18.76px"><br></span></font></div><div><font face="Arial, sans-serif"><span style="font-size:18.76px">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 </span></font><span style="font-family:Arial,sans-serif;font-size:18.76px">ISRG Root X1 is in the store<br><br>My config :<br>openssl version : </span>OpenSSL 1.1.1f  31 Mar 2020 </div><div>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</div><div><span style="font-family:Arial,sans-serif;font-size:18.76px">ISRG Root X1 self signed is in my cert store.</span></div><div><span style="font-family:Arial,sans-serif;font-size:18.76px"><br></span></div><div>So from what I understand, trusted first is default in this version of openssl and the second path should be taken.<br><br>For the record s_client can valide the second path on my machine :</div><div><font size="1">$ echo | openssl s_client -connect <a href="http://retouche-pro.ch:443/" target="_blank">retouche-pro.ch:443</a> -name <a href="http://retouche-pro.ch/" target="_blank">retouche-pro.ch</a> -servername <a href="http://retouche-pro.ch/" target="_blank">retouche-pro.ch</a><br>CONNECTED(00000003)<br>depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1<br>verify return:1<br>depth=1 C = US, O = Let's Encrypt, CN = R3<br>verify return:1<br>depth=0 CN = <a href="http://retouche-pro.ch/" target="_blank">retouche-pro.ch</a><br>verify return:1<br>---<br>Certificate chain<br>0 s:CN = <a href="http://retouche-pro.ch/" target="_blank">retouche-pro.ch</a><br>i:C = US, O = Let's Encrypt, CN = R3<br>1 s:C = US, O = Let's Encrypt, CN = R3<br>i:C = US, O = Internet Security Research Group, CN = ISRG Root X1<br>2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1<br>i:O = Digital Signature Trust Co., CN = DST Root CA X3<br>---    </font>     <br></div><div><br></div><div>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.</div><div><br>I also tried adding a verify callback on the ruby net http library (<a href="https://github.com/ruby/net-http" target="_blank">https://github.com/ruby/net-http</a>) which is passed to SSL_CTX_set_verify under the hood and I also noticed that it's using the "wrong" chain.<br><br>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 ? <br><br>If it's normal behavior how can I have additional certificate verification on the trusted first chain.<br><br>Thanks for reading,  I hope it was not too boring or confusing.<br>Alex</div></div>