Thank you for your responses. 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.
Am Do., 19. März 2026 um 03:39 Uhr schrieb Viktor Dukhovni via Postfix-users <[email protected]>: > On Wed, Mar 18, 2026 at 05:13:06PM +0100, Pascal von Ow via Postfix-users > wrote: > > > Am I right, that in the future you will no longer be able to use public > ssl > > certificates (because they lack the "Client Authentication" EKU) if you > use > > a policy service with ccert_*" attributes or configuration depending > > on smtpd_tls_ask_ccert/smtpd_tls_req_ccert? > > Actually, they can still be used, but they will not be considered > "trusted" (WebPKI authentication will fail), however (with ask_ccert) > the TLS handshake will complete and the public key digest will still be > available for authorisation. The policy service just won't see the > no longer trusted issuer and subject "CN" values. > > If, however, you use "smtpd_tls_req_ccert = yes", instead of the > generally more applicable "smtpd_tls_ask_ccert = yes" then indeed you'll > not be able to support newer WebPKI certificates that lack a clientAuth > EKU. > > > If I increase the TLS logging I still see the information logged, so it > > must be there but I can not use it in the policy. Is there any > alternative > > to check the certificate used for TLS if its lacking the client > > authentication EKU? > > Authorise client certificates by their public key hash. Do not trust > some random 3rd-party CA to authorise your trusted TLS clients. > > If your use-case is a walled-garden of independent peers relying on > the WebPKI to authenticate each other (EMIG-like scenario), and static > client public keys are not viable, you may be out of luck, unless > the group finds a mutually agreeable CA outside the Google root program > to issue the client certificates. > > -- > 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]
