On 31/05/2022 21:14, Viktor Dukhovni via Exim-users wrote:
TLS alerts report error conditions from the remote peer. If your server logs a TLS alert, that alert was generated on the remote end. So if this is a connection from a client to your server, then the "certificate expired" condition is something that the client believes to be the case.
Thanks for the clarification. So the issue is the client verification of the server cert, not a client cert.
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 X3The DST Root CA is expired. You can configure LE to build a "fullchain.pem" using the ISRG root instead. The only downside is that old Android systems may no longer be able to verify your chain.
OK, so my original theory was right (and, if I understand rightly, this is an outdated client implementation). Is the solution 'certbot --preferred-chain "ISRG Root X1"' then? (As I mentioned, I currently use acme-tiny rather than certbot, which unfortunately doesn't seem to support choosing the chain [1], so I guess I have to switch)
You can use a different cert chain for submission than for port 25 (where you're unlikely to need Android support).
Indeed. Thank you very much for the advice! Tim [1] https://github.com/diafygi/acme-tiny/issues/255 -- ## 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/
