On Wed, Dec 17, 2025 at 12:08:45PM +0000, Martijn Brinkers via Postfix-users
wrote:
> > The Postfix SMTP client just sends the certificate along, what the
> > server makes of it is the server's problem.
>
> The reason I'm asking is that the line "...hence pass the "openssl
> verify -purpose sslclient test" was interpreted by me as that the
> client certificate is not used if this test fails which in my case it
> fails:
>
> $ openssl verify -verbose -purpose sslclient -CAfile test.pem test.pem
> error 26 at 0 depth lookup: unsuitable certificate purpose
> error test.pem: verification failed
>
> I just wanted to confirm that Postfix will still use the certificate
> for client TLS auth even if the "sslclient" test fails. Whether or not
> O365 accepts it is a different story (it looks like it does but I
> asked Microsoft for confirmation)
The Postfix SMTP client (and underlying OpenSSL library) does inspect
its own (client) certificate closely enough to know whether an EKU
extension is present, or what is content might be.
That said, Google's abuse of power to force the WebPKI CAs to change
certificate issuance practices to drop the "clientAuth" EKU is not
entirely without a rational basis, it is just the not the right way
to address the underlying issue, specifically:
- Server's accepting client certificates in the majority of cases
SHOULD NOT rely on third-party CAs to identify the server's
TLS clients.
- Server operators that understand the security model, should
either use their own CA to issue certificates to clients, or
just curate a database of acceptable end-entity public keys
or certificates, and the associated identity or access grant.
So one could interpret Google's insistance as a kind paternalistic
gesture that improves the security of third-party internet services. Or
as a "my way or the highway", overreach that ignores anything other than
their own use-case. You decide.
The point of the above rant, is that if at all possible, your client
certificate for authenticating to Microsoft, SHOULD NOT be one that is
issued by Let's Encrypt, which Microsoft SHOULD NOT trust to
authenticate your system as a client.
Rather, it should be either issued *by* Microsoft, or be self-issued,
or be issued by your own CA, and appropriate configuration settings
on the Microsoft end should be in place to allow that certificate to
be used. It would typically then have a long (multi-year or decade)
expiration, and, as needed, you'd work with Microsoft to configure a
replacement trusted EE or CA-cert.
The Let's Encrypt certificate's signature attesting to your server name
as a server is meaningless in the context of connections from you to
Microsoft's services. Or if it is not meaningless in Microsoft's eyes,
then Google's overreach is all the more evident.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
