Why is GoDaddy removing ClientAuth EKU and transitioning to the R1 root hierarchy for DV TLS issuance?
Starting June 15, 2026, publicly trusted SSL/TLS certificates issued for server use will no longer be allowed to include the “Client Authentication” (EKU: clientAuth) extended key usage. Here are the key points to understand:
- The change is part of the Chrome Root Program policy update: new certificates must include only the “Server Authentication” EKU.
- New public certificates issued after that date which include clientAuth will not be trusted by Chrome.
- Certificates issued with clientAuth before June 15, 2026 are not impacted by this change, and will remain valid until they expire or are revoked.
- Private-CA certificates (for internal use) are not impacted by this change—it applies only to publicly trusted certificates.
In short: if your organization uses public TLS certificates for client authentication (via clientAuth EKU), you’ll need to act before June 15, 2026. For standard website TLS usage (server authentication only), this change does not require action. However, it’s a timely reminder to review your certificate of usage, separate functions appropriately, and ensure you’re aligned with the evolving trust model.
How GoDaddy will implement this change
Our current G2 signing/issuing intermediates do not have any EKU listed, which makes that hierarchy out of compliance with the Chrome Root Program requirement. As a result, issuance from the affected G2 intermediates must stop by that date.
Rather than creating new issuing intermediates on the G2 chain—which is planned to be expired/ended with Google in April 2027—we are moving DV issuance to our new R1 hierarchy to meet the policy constraints going forward.
We're changing the public DV issuance chain so new DV leaf certificates are issued from the GoDaddy TLS Root CA – R1 hierarchy, using the GoDaddy TLS Intermediate CA DV – R1v1 issuing CA certs.godaddy.com. This means the issuer chain presented by servers (leaf + intermediate) may differ from what some systems have historically seen, and any internal tooling that assumes a specific legacy intermediate name or chain order must be updated to accept the new R1 chain.
In addition, leaf certificates issued from this hierarchy will not contain ClientAuth EKU. Any workflow that was relying on DV leaf certificates being usable for TLS client authentication must migrate to an appropriate certificate profile/PKI path. During rollout, certificates remain operational in browsers because clients validate using the required R1→G2 cross-signed trust path published in our repository (certs.godaddy.com).
How certificates remain browser-operational during the R1 transition (R1→G2 cross-sign)
As we migrate public DV TLS issuance to the R1 hierarchy, the R1 root is still in the process of being broadly trusted/distributed in browser and OS trust stores. To ensure newly issued R1 certificates work immediately in browsers, we rely on a cross-signed trust path back to the already-trusted G2 root.
In practical terms, the leaf certificate is issued under the R1 DV issuing CA, but clients validate it by building a chain to GoDaddy Class 2 Root – G2 using the published R1→G2 cross certificate. The relevant artifacts in the repository are the G2 trust anchor (gdroot-g2), the cross certificate (gd_tls_root-r1-cross-g2), the R1 DV issuing intermediate (gd_tls_issuing_dv-r1v1), and the native hierarchy root (gd_tls_root-r1) certs.godaddy.com. This cross-sign approach allows browsers to validate the chain today (anchoring at G2), while R1 trust propagates over time.
Why is this change being made?
There are several reasons for moving away from certificates that support both serverAuth and clientAuth (also known as mixed-purpose certificates):
- Separating server authentication from client authentication helps simplify the certificate trust model.
- Improved security hygiene: Certificates with too many purposes increase risk (that is, misuse of clientAuth in unintended ways).
- Using dedicated PKI hierarchies for distinct functions helps maintain clearer trust boundaries, aligning with broader PKI (Public Key Infrastructure) best practices.
What are the benefits of this change?
- Reduced risk from multipurpose certificates: By restricting public certificates to serverAuth only, the attack surface is reduced, and trust-boundaries are clearer.
- Better compliance & governance: Organizations will have clearer separation between server authentication and client authentication, which can support better auditing and certificate lifecycle management.
- Improved operational clarity: When clientAuth functionality is separated into appropriate certificates or infrastructure, it’s easier to manage roles, revocations, renewals and ensure the right certificate is used for the right purpose.
- Future readiness: This change aligns with evolving PKI / browser trust models and helps position organizations for newer security models and automation.
Who is not affected?
Most websites that use certificates for server authentication only (that is, typical TLS/HTTPS) are not impacted. If you only ever use the certificate to secure your website for users, this change does not require action.
Who is affected?
This change affects organizations that use publicly trusted server certificates for client authentication (also known as mutual TLS / mTLS) or server-to-server authentication that rely on the clientAuth EKU. For example, some financial services, SaaS services, or multi-tenant APIs may be affected by this change.
What you need to do
- If you are hosted outside of GoDaddy: Ensure that the full bundle provided by the download endpoints or customer interface is being installed when updating your next certificate.
- If you are using certificates in any use case that rely on ClientAuth (mTLS): Ensure that you migrate those workflows to use a self-signed certificate or private CA solution.
Teams should also confirm that no internal feature or documentation assumes DV leaf certificates include ClientAuth EKU, since R1-issued leaf certificates will not include it.
Does this mean all certificates issued after June 15, 2026, are invalid?
No. Certificates issued before June 15, 2026, that include clientAuth remain valid (until expiration) under the existing trust model. The change only affects new public certificates issued on or after that date.
If I only use my certificate for typical website HTTPS (server authentication), do I need to do anything?
If your hosting is outside of GoDaddy, you still need to ensure that the bundle is correctly used.
What exactly is “client authentication” in this context?
Client authentication refers to the use of a certificate by a client (user, device or another server) to authenticate to the server. It’s commonly used in mTLS (mutual TLS) or server-to-server API authentication where the server needs to verify the certificate presented by the connecting client.
Can I still use clientAuth certificates at all?
Yes—but for public trust you will need to use a certificate specifically issued for client authentication (that is, dedicated clientAuth EKU) or use a private CA for your internal systems. Public server certificates with clientAuth EKU will no longer be trusted in Chrome if issued after June 15, 2026.
Will other browsers enforce this change or just Chrome?
The policy originates from the Chrome Root Program, but changes in the public PKI ecosystem often influence other browsers and trust stores. It’s wise to assume broader applicability or at least that future compliance will matter across platforms.
Does this apply to internal/private CA certificates?
No—the change affects only publicly-trusted SSL/TLS certificates (those trusted by the public root stores). Private CA infrastructure used for internal client authentication is not directly impacted.
When do we need to be ready for this change?
The target timeline is May 27, 2026. By that date, responsible teams should have completed readiness validation (issuance configuration, bundle/download correctness, deployment chain installation guidance, monitoring, and EKU dependency checks) so the rollout can proceed without service disruption.