Dual-Use Certificates Are Ending: The clientAuth Ban and What Breaks in 2027

For years, one public SSL/TLS certificate could quietly do two jobs. Many so-called dual-use certificates carried both the serverAuth and clientAuth Extended Key Usage (EKU) values, so the same certificate that secured a website over HTTPS could also present itself as a client credential for machine-to-machine authentication. That convenience is going away. Ballot SC-081 from the CA/Browser Forum removes the clientAuth EKU from public TLS certificates, and the Chrome Root Program has set a hard cutoff on March 15, 2027. If any of your systems reuse a web certificate for client authentication, they will break when those certificates renew. This post explains what a dual-use certificate is, exactly how the breakage happens, and how to separate the two use cases before a renewal takes a service offline.

This is part two of our look at SC-081. Part one covered the shrinking lifespans of SSL certificates, the other half of the same ballot. Here we cover the split between server authentication and client authentication, which is the change most likely to cause a surprise outage.

What a dual-use certificate actually is

Every X.509 certificate can declare what it is allowed to be used for. The Extended Key Usage field is the relevant part here. Two values matter for this discussion: serverAuth (OID 1.3.6.1.5.5.7.3.1), which says the certificate may identify a server in a TLS handshake, and clientAuth (OID 1.3.6.1.5.5.7.3.2), which says the certificate may identify a client. If you are fuzzy on how a TLS handshake proves identity in the first place, our plain-English guide to HTTPS and SSL/TLS is a good place to start.

For most of the web-PKI era, publicly trusted certificates shipped with both EKUs present by default. A certificate bought for www.example.com would assert serverAuth and clientAuth together. Nobody thought much about it, because the second value was harmless for a plain website. But that default is exactly why dual-use certificates spread into places they were never designed for. Teams building mutual TLS (mTLS), service-to-service authentication, VPN logins, or device identity discovered that a cheap public certificate already carried clientAuth, so they reused it as a client credential instead of standing up a separate system. The certificate was doing double duty, and the wider web PKI was silently propping up authentication use cases it was never meant to serve.

What SC-081 changes

SC-081 makes public TLS certificates single-purpose. Going forward, a certificate issued from a publicly trusted CA for web serving asserts serverAuth only. The clientAuth EKU is removed. The reasoning is sound: the public web PKI is optimized for one job, proving server identity to browsers, and mixing an unrelated authentication purpose into the same certificates makes the whole ecosystem harder to reason about and secure. Separating the roles means each certificate does one thing, and the rules that govern web certificates stop leaking into client-authentication systems that have very different needs.

The change lands in stages rather than all at once. Certificate Authorities began dropping clientAuth from default public issuance during autumn 2025. New subordinate (intermediate) CA certificates disclosed to the Common CA Database (CCADB) on or after June 15, 2026 must assert serverAuth only. And the immovable date is March 15, 2027.

The timeline that matters

Here is the sequence in plain terms:

• September and October 2025: Major CAs, including DigiCert and Sectigo, began removing clientAuth from newly issued public TLS certificates by default. Let’s Encrypt dropped it from its default chain in early 2026.
• June 15, 2026: New intermediate CA certificates disclosed to CCADB must be serverAuth-only, which pushes the constraint up the chain.
• March 15, 2027: The hard cutoff. Every newly issued leaf certificate that chains to a Chrome-trusted root must be serverAuth-only. From this date, Chrome rejects public TLS leaf certificates that still carry the clientAuth EKU, and the affected handshakes fail.

One detail saves a lot of panic: certificates issued before a CA’s change date keep their existing EKUs and stay valid until they expire. Nothing you already deployed stops working overnight. The exposure appears at renewal, when the replacement certificate comes back serverAuth-only.

How dual-use certificates cause outages

Because the failure is tied to renewal rather than a flag-day switch, it tends to arrive quietly and look random. A service that used a public certificate for client authentication keeps working right up until that certificate is reissued. Then the new certificate lacks clientAuth, and the far side of the connection refuses it.

The symptoms are consistent once you know what to look for:

• TLS handshake failures on connections that worked yesterday, immediately after a certificate renewal.
• Explicit EKU errors, often phrased as "unsupported certificate purpose," "certificate rejected," or a complaint that the certificate is not valid for client authentication.
• Authentication failures in an mTLS or API integration where the server side validates the client certificate’s EKU and now finds serverAuth only.

Because automated renewal tools such as ACME clients often reissue certificates on their own schedule, the outage can land at 3 a.m. on a certificate you had forgotten was doing two jobs. That is the trap of dual-use certificates: the reuse is invisible until the renewal that removes clientAuth quietly severs the authentication half.

Where you are likely exposed

The reuse pattern shows up in more places than most teams expect. Review anything that presents a certificate as a client identity:

• mTLS to internal or partner APIs, where a service authenticates itself with a certificate rather than an API key.
• Service-to-service authentication inside a microservices estate or across a service mesh.
• Device and IoT identity, where fleets were provisioned with public certificates for both TLS and client login.
• Enterprise plumbing such as VPN client authentication, RADIUS and 802.1X network access, and certain Exchange or messaging integrations.

Normal web browsing is not affected at all. A visitor loading your site over HTTPS never needed clientAuth, so a serverAuth-only certificate serves them exactly as before. The blast radius is limited to systems that repurposed a public web certificate as a login credential.

How to fix it before renewal

The fix is conceptual as much as technical: stop asking one certificate to be both a web server identity and a client login. Split the two.

Start with an inventory. Enumerate your certificates and check the EKU field on each one. Any certificate that asserts clientAuth and is issued by a public CA is a candidate for trouble. Tools that read the certificate’s extensions, or a scripted openssl x509 -text sweep across your inventory, will surface them quickly.

For the systems that genuinely need client authentication, move them off the public web PKI. A private CA or internal PKI can still issue certificates with the clientAuth EKU, because the SC-081 restriction applies only to publicly trusted TLS certificates. You control the policy on your own CA, so dedicated client certificates for mTLS, device identity, and server-to-server auth remain fully available there. A dedicated client-authentication issuer is the right home for those credentials, and it also gives you cleaner lifecycle control than a general-purpose web certificate ever did.

Do the separation before the next renewal, not after. If you wait until a serverAuth-only certificate has already replaced the dual-use one, the discovery happens as an incident rather than a planned migration. Treat this like any other credential hygiene project: knowing which certificates you hold and what each one is actually for is the same discipline that underpins the confidentiality, integrity, and availability goals of the CIA triad. The teams that inventory early will treat the 2027 cutoff as a non-event.

Frequently Asked Questions