Oct 26 12:05:11 mailserver postfix/smtps/smtpd[2041]: connect from client.lan[192.168.1.4]
Oct 26 12:05:11 mailserver postfix/smtps/smtpd[2041]: SSL_accept error from client.lan[192.168.1.4]: 0
Oct 26 12:05:11 mailserver postfix/smtps/smtpd[2041]: warning: TLS library problem: error:14037416:SSL routines:ACCEPT_SR_KEY_EXCH:sslv3 alert certificate unknown:/usr/src/lib/libssl/ssl_pkt.c:1200:SSL alert number 46:
Oct 26 12:05:11 mailserver postfix/smtps/smtpd[2041]: lost connection after CONNECT from client.lan[192.168.1.4]
Oct 26 12:05:11 mailserver postfix/smtps/smtpd[2041]: disconnect from client.lan[192.168.1.4] commands=0/0
This just started lately couple of days ago. I did not change any config on this mailserver since 2021 and now its starting to misbehave. It looks like some issue with your cert.
The cert is getting renewed and installed for both postfix/nginx all right but the android gmail mail client seems like refusing it now.
According to the Qualis ssl scan:
Revocation information CRL
CRL: http://r12.c.lencr.org/83.crl
Revocation status Validation error
CRL ERROR: IOException occurred
This is commonly reported incorrectly by Qualys. You can safely ignore that
As for the main problem:
What is the domain name? Is it accessible from the public internet?
Do you "pin" (hardcode) the intermediate cert? Because on Aug20 Let's Encrypt started using new intermediates. If this was your first renewal since then it could be related. If so, the correction is to stop pinning intermediates. If you've been running since 2021 this probably isn't it because LE has rotated intermediates before.
Are any other clients failing to connect? Or is it just the android mail client?
No it's just the android one, various versions of thunderbirds can connect no problem.
No I don't hardcode it.
/root/.acme.sh/acme.sh --issue -k 4096 --server letsencrypt --force --dns dns_nsupdate -d domain.com -d *.domain.com --reloadcmd /root/cert_renew.sh
Then I concatenate the key + the fullchain into a pem file and this is what nginx and postfix are using. No change on my end since many years.
I don't know how it can be an issue with the cert if other clients connect with no problem. And, I assume the Qualys report was otherwise successful apart from their faulty CRL check.
I'd only suggest looking at other possible incompatibilities. Perhaps the android client has changed and now requires something your server (unchanged since 2021) should have. Review things like ciphers and key types (RSA, ECDSA).
Is it one specific system's android mail client or a wide audience of them? Maybe something has gone wrong or changed in that client.
Not much more I could say without the actual domain name.
Perhaps some other volunteer with more experience with mail systems will have more to say.