On 2022-05-31 at 14:33:19 UTC-0400 (Tue, 31 May 2022 20:33:19 +0200)
Tim Jackson via Exim-users <li...@timj.co.uk>
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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/