On Thu, Apr 02, 2026 at 03:43:52PM +0200, A. Schulze via Postfix-users wrote:
> We operate SMTP servers using a valid SMTP server certificate.
> we ask SMTP clients for a certificate ( smtpd_tls_ask_ccert = yes )
Why?
> our SMTP server are reachable only for one external organisation, not
> a public MX Over the last years, we saw 100% "Trusted TLS connection
> established from ..."
>
> Since April 1 2026, 8 am UTC, we have 1% untrusted connections.
> Even the same SMTP client ip switch between Trusted/Untrusted multiple times
> per hour.
Perhaps because in accordance with the Google Chrome Root Pragramme
policy, mainstream (WebPKI) public CAs are ceasing to issue "clientAuth"
certificates. When certificate carries only the "serverAuth" EKU, it
will no longer validate as a TLS client certificate.
> To me, it looks like the remote side reuse IPv4 adresses for multiple
> SMTP client instances and some (~1%) of them is misconfigured since
> yesterday.
You may see this fraction grow in the coming days and weeks.
> after some time, I had a hit. But the debug log did not contain TLS
> relevant information like presented certificated or chain data.
For that detail, you'd need to change the "smtpd_tls_loglevel", and
perhaps use "iptables" to redirect traffic to an alternate port if
you want TLS debugging for just that IP address.
> I think, I would have to set "smtpd_tls_loglevel = 2" (currently 1)
> But I'm unsure, if this - unlike debug_peer_list - affect all traffic.
It affects all traffic, that's why a dedicate IP:port is needed.
> So, what are other opportunities? In the mean time I will start to use
> tcpdump ...
With TLS 1.3 "tcpdump" won't help you, client certificates are not sent
in the clear with TLS 1.3. Only with TLS 1.2 would you be able to learn
anything about the client certificate from "tcpdump".
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
