On 2022-05-31 at 14:33:19 UTC-0400 (Tue, 31 May 2022 20:33:19 +0200)
Tim Jackson via Exim-users <lists@???>
is rumored to have said:
> I have some legitimate-looking hosts from a major bank producing log
> lines like this when attempting incoming connections to a public MX:
>
> TLS error on connection from r209.notifications.natwest.com
> [130.248.154.209]:44104 I=[167.235.252.255]:25 (SSL_accept):
> error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate
> expired
>
> Is this me (server) dropping the connection or them?
Them.
> (From the log, it reads a bit like me, but I'm definitely not trying
> to do any client certificate verification so it's unclear which
> certificate is "expired"). I'm far from an expert on TLS, but I
> believe I have a sane certificate chain (up to date from Let's Encrypt
> via acme-tiny; neither the cert nor the CA certs are expired). Other
> hosts successfully send mail via TLS all the time; it's only this
> specific group of hosts (*.notifications.natwest.com) where I'm seeing
> the issue.
>
> Is this likely an instance of the Let's Encrypt issue [1][2], where
> the client is using an old/buggy SSL implementation?
Yes, it is likely the referenced issue, but that's NOT an "old/buggy SSL
implementation" it's an obsolete secondary signing chain used for LE
certs before last year.
> I can exclude these hosts via tls_advertise_hosts to (presumably)
> "solve" the issue, but it would be interesting to know if
>
> - I could/should do anything different (e.g. Workaround 3 from [1],
> i.e. request a different CA chain?), or
Yes. Workaround 3 is what everyone using LE certs should do.
> - just put it down to a broken client.
No. This can be fixed client-side but the root cause is fundamentally a
certificate trust chain error and the client is arguably Not Wrong in
considering the cert bad.
> (I've been using this configuration for quite a while and don't recall
> ever seeing this issue before).
>
> Environment: Exim 4.94.2 / Linux / OpenSSL 1.1.1k
>
> # exim -bP tls_try_verify_hosts
> tls_try_verify_hosts =
> # exim -bP tls_verify_hosts
> tls_verify_hosts =
>
> # openssl s_client -starttls smtp mx1.firecluster.net:25
> CONNECTED(00000003)
> 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 = mx1.firecluster.net
> verify return:1
> ---
> Certificate chain
> 0 s:CN = mx1.firecluster.net
> 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
A working LE chain will terminate with:
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
Which should work because by now, everyone should have a self-signed
root cert with "CN = ISRG Root X1" in their trust store.
--
Bill Cole
bill@??? or billcole@???
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
