As industries evolve, so too does the implementation of their existing technologies. Public Key Infrastructure (PKI) is no different. Many organizations are preparing for the widely anticipated Client Authentication EKU sunset, alongside the TLS Certificate Lifetime Reduction proposed by CA/Browser Forum, which recommends to reduce certificate lifetimes down to a maximum of 47 days starting in 2026. Other industry changes are being implemented as well, and one worth calling out is Google’s Chrome Root Program Policy’s changes regarding how TLS certificates can be used. This change will means certificates issued from public CAs that not abiding Google’s policy will no longer be trusted in Chrome starting on June 15th, 2026. While this change won’t impact internal or private CA environments, the resulting changes to TLS certificates issued by certification authorities abiding Google’s requirements might prevent newly issued certificates from working in certain cases that might have been working previously.
Understanding the Change
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Not all certificates are issued equally. Certificates are issued with EKU (Enhanced Key Usage) policies. These policies serve to inform what the certificate should be used for. This design helps to ensure certificates are only used with their original intention in mind. For example, code generally can’t be signed with a TLS certificate because the required EKU (Code Signing) is not included in a typical TLS certificate. Another common example is the requirement to create a special certificate template in AD CS for things that require the Kerberos Authentication EKU.
Common EKUs include things like:
- Client Authentication
- Server Authentication
- Code Signing
- S/MIME (Email protection)
- Smart Card Authentication
If you look at the properties of a certificate like the one shown in Figure 1, you can see what EKUs are included in the certificate. The EKUs are “baked in” to the certificates themselves and cannot be modified once issued.
Historically, TLS/SSL certificate issuance practices often bundled both Server Authentication and Client Authentication EKUs. Despite this, there is virtually no reason why a web server ever needs to verify itself as a client. Given this, the industry is moving to issue TLS certificates that include only the EKUs that are truly required for usage.
How Will This Impact My Organization?
If your organization is using TLS certificates solely for their intended purpose of encrypting web server traffic, then no action is required.
If your organization is using a TLS certificate issued from a public CA for something other than a web server (as many organizations do), it is imperative to understand whether the client certificate capability is required. Below we’ll highlight a few common examples where the Client Authentication EKU is required.
Hyper-V Replication
When configuring Hyper-V replication Microsoft explicitly notes that the certificate requires both Server and Client Authentication EKUs due to the mutual authentication process required for replication to succeed. In the event Hyper-V replication was configured with a public certificate, which is explicitly allowed, a new TLS certificate issued from public TLS certificates would no longer meet the requirements for replication.
Cisco ISE
The very first line of the Cisco ISE Certificates Guide notes that both client and server authentication is required for mutual authentication. Cisco calls out using “CA-signed certificates” for both HTTPS and EAP. In the case that a certificate issued from a public CA was used for this, HTTPS would likely continue to work, but EAP could break. Note that some platforms allow a single certificate to serve multiple purposes, which is not uncommon when dealing with complex identity and client identity workflows.
Other Third Party MTLS
Mutual TLS (mTLS) requires both parties to authenticate as a server and a client, meaning both EKUs are mandatory. Many applications and middleware platforms leverage mTLS, where the TLS Client Authentication requirement is fundamental.
Preparing for the Change
To prepare for a seamless transition, it is important to understand where your organization has deployed public certificates. There is no way to ensure newly issued certificates will work other than to verify the documentation for each product or service you plan to continue protecting with publicly trusted certificates.
If you determine that the ClientAuth EKU is required, you must plan how to reissue the certificate containing the appropriate EKU.
If you have an internal PKI, consider issuing the replacement certificate from that PKI instead. There are very few situations that require both the Client Authentication EKU and trust from a Certificate Authority that is publicly trusted. For infrastructure services, consider migrating away from leveraging certificates from publicly trusted CAs.
Conclusion
Industry changes like removing the Client Authentication EKU from TLS certificates are easy to miss. This change to the EKUs in public trusted certificates is particularly insidious. Organizations that are already on top of their PKI configuration and usage will likely not be severely impacted by this change. Organizations that do not have a full understanding of how their certificates are being used may be blindsided during a future scheduled certificate renewal or reissuance.
Do you need help auditing your certificates or figuring out if you might be impacted by industry changes to PKI? Get in touch with one of our experts at Ravenswood today!
