CSR/EKU behavior of free ACME CAs

Client dev
1

I had a user submit an issue recently about how Google started rejecting CSRs that include the Client Auth EKU unless the client appends ?client_auth=true to the end of the directory endpoint. And the directory override will only work until next month.

In any case, the CSRs generated by my client have always included both Client and Server EKUs and they were asking if that could be changed to only include Server because of the Google changes and make the Client EKU opt-in. But being a technically breaking change in my client, I was curious how it would affect the other free ACME CAs and wanted to share my findings with the community.

Obviously these findings are subject to change as the Client Auth EKU deprecation moves forward. Also, the only EKU combinations I tested were Server-only and Client+Server. So the "seems to ignore EKUs" findings may change for other uncommon EKU inclusions.

Let's Encrypt

  • seems to ignore EKUs in CSRs
  • all certs contain EKUs based on ACME profile

Google

  • Until 2026-04-13, rejects CSRs with Client Auth EKU unless ?client_auth=true is appended to the directory endpoint.
  • After 2026-04-13, always rejects CSRs with Client Auth EKU

ZeroSSL

  • seems to ignore EKUs in CSRs
  • all certs only contain Server Auth EKU

SSL.com RSA directory

  • rejects CSR with only Server Auth EKU with error, Requested extended key usage will not be granted
  • when Client+Server EKU included, resulting cert contains both Client+Server EKU

SSL.com ECC directory

  • accepts CSR with only Server Auth EKU and Client+Server EKU
  • all resulting certs only contain Server EKU

Actalis

  • seems to ignore EKUs in CSRs
  • all certs contain both Server+Client EKUs

So in summary, the only CAs that seem to care about the EKUs in submitted CSRs are Google and SSL.com, but SSL.com also seems kind of broken. And for the CAs that don't, the EKUs in your resulting cert are definitely not consistent yet.

6 Likes
2

That's interesting. Thanks

Is omitting both EKUs a viable option? I don't set either EKU in my custom client but I only use LE and GTS regularly.

Perhaps omitting both would get consistent results from SSL.com ?

2 Likes
3

I can test it for science, but I probably won't make that change in my client just to hopefully minimize the potential breakage with other CAs I can't test.

SSL.com has always seemed to have a pretty janky ACME implementation. They still don't support POST-as-GET on a number of endpoints like their account endpoint. And error messages are all over the place.

4 Likes
4

Sure, but, don't you have to make some kind of change anyway? At least offering an option to do something other than your default of including both Server and Client EKU in the CSR.

If I read your results correctly GTS will start failing with your client fairly soon.

2 Likes
5

Oh yeah, I'm likely changing my default to include Server Auth only. I just meant I probably wouldn't make an option (at least in the current version) to include no EKUs.

3 Likes
6

From memory I think in Certify The Web we've omitted both client and server EKUs for a few years, we haven't had any complaints about that.

The only thing that has been problematic was trying to remove CN and just use SAN - support for that is quite patchy.

3 Likes
7

I realized my initial SSL.com ECC test was flawed because I had been trying to send an RSA based CSR instead of an ECC one like a dummy. I edited my original post with the updated results. It's still weird that they have different behaviors.

I also did some more testing tonight with no EKU extension at all in the CSR. Here are those results and it's actually overall a better result since none of the CAs threw an error. I'm probably going to just abandon sending the EKU extension like apparently others have.

Let's Encrypt

  • accepts CSRs with no EKUs and signs certs with EKUs based on profile

Google

  • accepts CSRs with no EKUs and signs certs with only Server EKU

ZeroSSL

  • accepts CSRs with no EKUs and signs certs with only Server EKU

SSL.com RSA

  • accepts CSRs with no EKUs and signs certs with Client+Server EKU

SSL.com ECC

  • accepts CSRs with no EKUs and signs certs with only Server EKU

Actalis

  • accepts CSRs with no EKUs and signs certs with both Client+Server EKU
5 Likes