Client certificate not sent during TLS handshake when Client Authentication EKU is missing (Certificate Authorities change 2026)

[YurivanRuler]

Description

Starting October 1, 2025, DigiCert (and other Certificate Authorities as well) will no longer include the Client Authentication EKU by default in public TLS certificates (DigiCert announcement). Certificates will be issued with Server Authentication EKU only unless ClientAuth EKU is explicitly requested during enrollment. This change aligns with industry-wide plans to phase out ClientAuth EKU from public TLS certificates.
In .NET (System.Net.Http → System.Net.Security), the CertificateHelper logic validates client certificates based on EKU and KeyUsage, relevant code located in CertificateHelper.

Because of this logic, certificates without Client Authentication EKU are considered invalid and are not sent during the TLS handshake. This surfaced in our environment when establishing a TLS connection: the client certificate was never presented, causing mTLS authentication to fail. A discussion about this topic from 2023 is closed GitHub issue 94152

Expected Behavior

I am not an expert in authentication, but based on my understanding and recent industry developments, I believe the current logic may not align with upcoming changes from major certificate authorities. To avoid future disruptions and ensure compatibility, it would be valuable to review and adapt this implementation to reflect these market trends.

.NET should possibly allow the certificate to be sent even if Client Authentication EKU is missing. This would prevent disruptions after DigiCert and other CAs remove Client Authentication EKU from public TLS certificates.

Actual Behavior

CertificateHelper.IsValidClientCertificate rejects certificates missing Client Authentication EKU.
As a result, the certificate is not offered during the handshake, and servers return 403 or similar errors in mTLS scenarios.

Impact

Organizations using public TLS certificates for mTLS will face production outages starting October 2025 when ClientAuth EKU is no longer included by default.
The risk increases by May 2026, when adding ClientAuth EKU may no longer be allowed at all.

Steps to Reproduce

• Use a public TLS certificate with ServerAuth EKU only.
• Configure HttpClientHandler with the certificate httpClientHandler.ClientCertificates.Add(certificate)
• Connect to a server requiring client certificate authentication (mTLS).
• Observe that the certificate is not sent and the server rejects the connection.

Workarounds

• Explicitly request ClientAuth EKU during certificate enrollment (temporary solution).
• Configure the certificate on the SocketsHttpHandler directly, example:
  .ConfigurePrimaryHttpMessageHandler(() => { var socketsHttpHandler = new SocketsHttpHandler(); var x509CertificateCollection = new X509CertificateCollection { X509CertificateLoader.LoadPkcs12(myCertificateBytes, password: null) }; socketsHttpHandler.SslOptions.ClientCertificates = x509CertificateCollection; return socketsHttpHandler; });

Proposed Fix / Discussion

• Relax EKU validation: Allow certificates without Client Authentication EKU.

References

DigiCert announcement
Earlier discussed issue
CertificateHelper

[MihuBot]

cc: @dotnet/ncl

[wfurt]

Any thoughts on this @bartonjs? It feels strange that we would consider certs with only Server EKU as valid for client. I would feel if there is nothing it would be OK. It also seems like if the certifier is meant for client AUTH one can easily ask for it...

[wfurt]

I was thinking about it more and it seems like there is push toward no client EKU for public certificates. That sort of assume IMHO that that client certs would be issued by private CA and have the client EKU? And if the server has only server EKU I assume we would exclude it from the search as we do today? Or since this was explicitly added to ClientCertificates we should consider them all? I'm on assumption that we would still accept whatever was selected by custom callback e.g. this debate is only relevant to automatic selection.

It seems like we should drive the decision for .NET 11 (and back port it if need to)
Any more thoughts on this @rzikm @bartonjs @vcsjones ???

[bartonjs]

The logic, as I see it is:

• No EKU extension: Send it.
• Has EKU extension, no client EKU: don't send it.

That sounds right to me. A certificate marked as "server authentication" only shouldn't be used as a client certificate. Nor should one marked as an OCSP responder, or a trusted timestamp authority, or ...

[vcsjones]

The Google Root Inclusion Policy requires that certificate authorities use different certificate hierarchies for server and client auth EKUs. This goes in to effect June 15, 2026. See 4.2.1 of the policy. The end result of this is that Chrome's Root Program will not allow using HTTPS server certificates that have the client auth key usage. So CAs need to remove the client-auth EKU. Google explains their reasoning a bit here.

Google's reasoning to me, is sound. It is mixing up public and private PKI.

.NET should possibly allow the certificate to be sent even if Client Authentication EKU is missing. This would prevent disruptions after DigiCert and other CAs remove Client Authentication EKU from public TLS certificates.

My 2c: this seems against the spirit of what the change is intending. Additionally, there is no telling how software will react to the missing EKU. A well-behaving server would likely reject a client certificate that is not eligible for client certificate use. Sending it does not imply acceptance.

[bartonjs]

It does look like "Manual" goes through that same path. I'm fine either way for that. (Both "do what's compatible" and "do what I say" make sense.) But, yeah, Automatic shouldn't gain laxity here. The client EKU still means something, it's just that the industry is splitting client and server trust apart into different hierarchies.

My vote is for "leave the code as it already is", unless there's a specific case someone wants to raise for "do what I say" in Manual.

[wfurt]

perhaps we shall check test coverage and add tests if needed to ensure compliance with desired behavior.