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 X3
>
> The 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
