[pfx] Re: howto debug "Untrusted TLS connection established from"
"A. Schulze via Postfix-users" <[email protected]>
| Newsgroups | gmane.mail.postfix.user |
|---|---|
| Message-ID | <[email protected]> |
Viktor Dukhovni via Postfix-users: > 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? I take that point to the team. The dumb answer for now "because it worked" But I agree: I've to ask "what is the benefit?" ... >> 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". ok, my challenge: force the client to use TLS 1.2 :-) Thanks for that... Andreas _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]