Hello Viktor We provide a service in which some mails from other organizations are not routed the normal way but through our service. This is normally not a special system that sends this emails but the normal mail gateway of the organization. So there is a normal certificate of a CA deployed there. To authenticate them we used a combination of the ip address, certificate fingerprint and domain. If there was a change, the organization informed us beforehand. This system is quite old and if I would start from scratch I would not do it again this way and it was fine as long the certificate was valid for 1 year or even longer before the lifetime got reduced. And also earlier it was quite static with not that much changing infrastructure.
So to be a bit more flexible with the certificate I implemented a policy service that checks the CN of the certificate and the issuing CA, so if the certificate was changed, it would still work. Now with the next change and the missing EKU for client authentication, I'm facing a new challenge and thats why I started this topic, because maybe there is something I was missing. But I think we should rethink the entire process and maybe implement authentication with SASL or self deployed client certificates as the people in this thread recommended. Am So., 22. März 2026 um 15:14 Uhr schrieb Viktor Dukhovni < [email protected]>: > Any chance you have some cycles to respond (on-list) to my question in > the attached post? > > -- > Viktor. 🇺🇦 Слава Україні! > > > > ---------- Forwarded message ---------- > From: Viktor Dukhovni via Postfix-users <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Fri, 20 Mar 2026 16:45:33 +1100 > Subject: [pfx] Re: Postfix SMTP Access Policy: ccert-attributes > On Thu, Mar 19, 2026 at 10:06:14AM +0100, P v via Postfix-users wrote: > > > I use the public key fingerprints at the moment, but this is no longer > > feasable with the shorter certificate lifetimes, so I was exploring other > > methods. I see that the approach with the ccert_* attributes is not > > something with a future. > > Can you take a moment to explain your use-case? Why do you need to > validate CA-issued client certificates whose underlying public keys > change without notice and outside your control? > > A typical client certificate scenario is one in which you operate some > remotely hosted systems and they need to use your submission services to > relay outbound mail through the "home" server, you'd provision a static > keypair on the remote end, and a self-signed certificate or even just a > raw public key is sufficient to authenticate the client against a > suitable access(5) table on your server (check_ccert_access). > > How is your situation different, and why are volatile CA-issued > certificates required and appropriate? > > -- > Viktor. 🇺🇦 Слава Україні! > _______________________________________________ > Postfix-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
