On Wed, Dec 17, 2025 at 10:42:23AM +0000, Martijn Brinkers via Postfix-users
wrote:
> I have a question about how postfix handles certificates for TLS
> client authentication which lack the TLS client auth Extended Key
> Usage extension.
Sure, the Postfix SMTP server? Or the Postfix SMTP client?
> Due to recent changes in the way certificates are issued by CAs, TLS
> server certificates issued by CAs no longer have the TLS client auth
> Extended Key Usage extension.
Not all CAs, just CAs in the Google (Chrome) Root CA programme.
> However, when setting up an O365 connector for sending email from
> "Your org" to "O365", it is recommended to use a client side
> certificate for authenticating the connection.
Since O365 is a Microsoft service, whose servers I expect run Microsoft
Exchange, are you asking about the Postfix SMTP client?
What makes a given certificate "valid" in this context? Does the
customer upload the expected client cert? Are some specific issuer
CAs trusted, and if so what is the expected client identity (SAN)
in the certificate?
> Now I'm investigating whether this could be problematic when
> authenticating from Postfix to O365.
The party to ask is then presumably Microsoft.
> To test with a trusted certificate, without the TLS client auth
> Extended Key Usage extension, I requested a certificate from Let's
> Encrypt using the tlsserver profile.
Why does "trusted" mean in this context? The sensible thing would be
for the customer to specify the client cert explicitly, or else
explicitly designate a suitable (private?) CA.
> This will then return a certificate without the TLS client auth
> Extended Key Usage extension.
Only if issued (ultimately) by a CA in Google (Chrome)'s root programme.
> My tests seem to indicate that Postfix will still be able to
> authenticate with the certificate when connecting to O365.
Well, that rather depends on what "authenticate" means. When the remote
server is Postfix, a client certificate that has an EKU extension but
its value excludes "clientAuth", will never be validated as a "Trusted"
(or "Verified") certificate, but the Postfix SMTP server will typically
not care, because it only cares about certificate or public key
fingerprints. Indeed in my configuration I have:
mtpd_tls_enable_rpk = yes
as a result of which the client does not even send the certificate at
all, it sends just the public key, so the server never sees the EKU.
But Microsoft's servers probably don't support RFC7250 raw public keys
just yet.
> However, if I look at the Postfix documentation, it seems that postfix
> will only use the TLS client auth Extended Key Usage extension if the
> certificate contains it:
That sentence makes no sense. With certificate-based auth the entire
certificate is sent, with whatever contents it may have, and so the EKU
is either presenet or absent, nothing the Postfix SMTP client can do
about that.
> [quote]
> A certificate supplied here must be usable as an SSL client
> certificate and hence pass the "openssl verify -purpose sslclient ..."
> test.
> [/quote]
This (somewhat dated perhaps) sentence assumes that the server will be
"verifying" the certificate (not just using it or its public key
directly as "raw" input for access control). If so, the EKU, if
present, needs to include "clientAuth". But the server may not be
looking to "verify" the certificate relative to some issuer CA chain.
> So my question is, will Postfix still be able to authenticate with the
> certificate if it does not contain the TLS client auth Extended Key
> Usage extension?
The Postfix SMTP client just sends the certificate along, what the
server makes of it is the server's problem.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
