[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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.