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
Anyone else run into this?
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?
3 Likes
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.
2 Likes
Well not Todays postfix postfix-3.4.9-sasl2 but also not reasonable to rugpull old algos unannounced from a mail client.
# TLS parameters
smtpd_use_tls=yes
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_security_level=may
smtpd_sasl_security_options = noanonymous
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_security_level=may
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
## Server chooses prefered cipher
tls_preempt_cipherlist = yes
smtpd_tls_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
lmtp_tls_protocols = !SSLv2, !SSLv3
tlsproxy_tls_protocols = $smtpd_tls_protocols
tlsproxy_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
smtpd_tls_ciphers = medium
smtp_tls_ciphers = medium
smtpd_tls_eecdh_grade = strong
smtp_tls_exclude_ciphers =
EXPORT, LOW, MD5,
aDSS, kECDHe, kECDHr, kDHd, kDHr,
SEED, IDEA, RC2
smtpd_tls_exclude_ciphers =
EXPORT, LOW, MD5, SEED, IDEA, RC2
#new
# SASL
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
As a fix I just configured another port unencrypted as the client is going through vpn anyway.