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]
