<div dir="ltr">Thanks for the detailed answer. <div><br></div><div>From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1</div><div><br></div><div>When I use the eventmachine lib that uses the wrong cert chain I can see with strace :<br><font size="1">openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)<br>stat("/usr/lib/ssl/certs/2e5ac55d.0", {st_mode=S_IFREG|0644, st_size=1200, ...}) = 0<br>openat(AT_FDCWD, "/usr/lib/ssl/certs/2e5ac55d.0", O_RDONLY) = 8<br>stat("/usr/lib/ssl/certs/2e5ac55d.1", 0x7ffe1a8e5d80) = -1 ENOENT (No such file or directory)</font></div><div><font size="1"><br></font></div><div>When I use another lib that uses the correct cert chain I can see with strace :<br><font size="1">openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)<br>openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)<br>stat("/usr/lib/ssl/certs/8d33f237.0", 0x7fff1b4b0f90) = -1 ENOENT (No such file or directory)<br>stat("/usr/lib/ssl/certs/4042bcee.0", {st_mode=S_IFREG|0644, st_size=1939, ...}) = 0<br>openat(AT_FDCWD, "/usr/lib/ssl/certs/4042bcee.0", O_RDONLY) = 8</font><br></div><div><font size="1"><br></font></div><div>In the second case I can see it tries to load the R3 certificate ( 8d33f237.0 ). I wonder why in the first case it does not try to find each certificate in the chain from the trust store at all. I wonder if it can be related to the fact I do not see any call to <span style="color:rgb(68,68,68);font-size:16px">SSL_CTX_set_cert_store<font face="arial, sans-serif"> </font></span><font face="arial, sans-serif"><span style="color:rgb(68,68,68)">in the lib. </span><span style="color:rgb(68,68,68)"> On the other hand I suppose if we do not call this it would pick the "default" trust store from the system which seems to be the case here because it can find </span>/usr/lib/ssl/certs/2e5ac55d.0 . </font><br></div><div><br></div><div>This looks like to be an issue in the eventmachine lib itself. I need to brush up my C skills and have a deeper look at this :).</div><div><br></div><div>Thanks</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 2, 2021 at 8:11 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Oct 02, 2021 at 06:21:00PM +0100, Angus Robertson - Magenta Systems Ltd wrote:<br>
<br>
> > Yes.  To make things even more complex, a few sites also have an <br>
> > older version of R3 that is directly signed by the DST root:<br>
> > <br>
> >      - leaf <- R3 <- DST Root CA X3 (self-signed)<br>
> > <br>
> > but that's far from common at this point.<br>
> <br>
> That old R3 [CA] was issued last winter and got installed in Windows<br>
> Server 2018 intermediate stores then, and was still being sent out on<br>
> 29th and 30th, despite expiring on 29th.  <br>
<br>
Not just Windows, at least one Unix system running Postfix is still<br>
vending a chain with the R3 signed by DST that expired on 2021-09-29:<br>
<br>
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3<br>
subject=C = US, O = Let's Encrypt, CN = R3<br>
notBefore=Oct  7 19:21:40 2020 GMT<br>
notAfter=Sep 29 19:21:40 2021 GMT<br>
SHA256 Fingerprint=73:0C:1B:DC:D8:5F:57:CE:5D:C0:BB:A7:33:E5:F1:BA:5A:92:5B:2A:77:1D:64:0A:26:F7:A4:54:22:4D:AD:3B<br>
-----BEGIN CERTIFICATE-----<br>
MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/<br>
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT<br>
DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow<br>
MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT<br>
AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs<br>
jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp<br>
Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB<br>
U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7<br>
gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel<br>
/xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R<br>
oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E<br>
BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p<br>
ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE<br>
p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE<br>
AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu<br>
Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0<br>
LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf<br>
r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B<br>
AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH<br>
ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8<br>
S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL<br>
qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p<br>
O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw<br>
UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg==<br>
-----END CERTIFICATE-----<br>
<br>
The EE (depth 0 server) certificate is not expired, and yet somehow the<br>
server is building a chain with a fresh leaf cert, and a rather stale<br>
issuer CA.<br>
<br>
It verifies via the DANE implementation in OpenSSL, because its "2 1 1"<br>
record with a fresh RRSIG specifies the R3 CA as trusted, and its<br>
expiration date is not in scope since it was signed by an entity outside<br>
the effective trust chain.<br>
<br>
Validation would fail for the same chain with WebPKI, unless there's a<br>
new improved R3 in the trust store (not just the roots).<br>
<br>
My DANE survey scan engine checks trust-anchor cert expiration date,<br>
even when an intermediate CA, mostly because the implementation is<br>
done that way, but I can retroactively justify it because it makes<br>
sense to be more strict in tools that look for potential issues.<br>
<br>
Implementations other than OpenSSL might similarly reject such a<br>
suboptimal chain.<br>
<br>
-- <br>
    Viktor.<br>
</blockquote></div>