Just at the time where all over the world discussions are happening to move mail servers back into organisations big and small instead of relying on the big email providers, due to risks associated with centralising email at (US) providers, you are willing to make life even more complicated for us postmasters. This is not what you should be doing. You should make it easier to use encryption instead of telling us postmasters find out ourselves where we can buy certificates in future.

2/5

@larsmb @Jpbrosnahan1 @AndiBarth

That not everyone out there can run a private CA/PKI and demanding that to be the requirement is an exclusive and not inclusive approach.

I find it hard to imagine that there are people who are capable of deploying the kind of systems that creates a need for PKI, who cannot run the tiny handful of openssl command line commands it needs.

Being able to configure a web or mail server that works with Let's Encrypt is at least as hard. Even installing a web server is almost as hard.

And that's assuming that they use the openssl command line directly. There are (open source) packaged wrappers that make it much easier.

While a lot is being talked about the security aspect, I have yet to see examples of security breaches caused by having ClientAuth EKU in a certificate

The problem is not having a ClientAuth EKU certificate, the problem is having a certificate that has both ServerAuth and ClientAuth EKU flags. These are different uses. A certificate is never simultaneously used for both. If you are establishing a connection and presenting a certificate, you want a client certificate. If you are accepting an incoming connection and presenting a certificate, you want a ServerAuth certificate.

Combining the two violates two of the most fundamental principles in computer security:

• The principle of least privilege. A certificate that combines the two violates this because it is combining two things that are never used together and so should be separate.
• The principle of intentional use. A certificate that combines the two violates this by providing a certificate that is easy to use in the wrong case.

There have been compromises as a result of trusting certificates that were issued for server use as clients and vice versa. This is why EKU was added in the first place, setting both the client and server EKUs misses the point. I'm not sure why LE ever did this. Especially since they've explicitly said on numerous occasions that they don't issue client certificates (which is a shame, I wish they'd provide a flow for issuing S/MIME certs).

Their certificates have very limited use for client auth. Most of the time you want more than a domain name when authenticating clients. You want to authenticate users and you want to authenticate them with some specific claim.

Server certificates are simpler because the claim that you want to authenticate with the certificate is that the owner of the domain name that you think you're connecting to is responsible for the other endpoint. With client certificates, simply binding to a domain rarely makes sense. For situations where this actually is what you want, protocols often use dial-back, where the server establishes a connection back to the server, which tells you both that they have the certificate for that domain and control (or can hijack connections to) the IP associated with that domain (XMPP does this, for example, because early 2000s anti-spam ideas thought that knowing the sending domain was useful, but this doesn't work for email because relaying complicates the whole thing).

@david_chisnall @Jpbrosnahan1 @AndiBarth But setting up a "PKI" for my (private/personal) use client certs (where I don't want an outside party to know the private key, nor there be any record in a public cert log) was quite easy?

The linked article (digicert.com/blog/how-the-clie…) drives this point home: "separate public and private trust" and suggests this makes sense?

I use mTLS quite a bit for my setups and using LE for that hasn't ever crossed my mind.

I must be missing something.

How the ClientAuth Crackdown Is Pushing Finance Toward X9 PKI

As of June 15, 2026, public TLS server certificates must no longer include the Client Authentication EKU. It will carry significant consequences for financial services.

^DigiCert