Public CAs Are Removing Client Authentication From SSL Certificates by March 2027: What You Need to Replace It With

Hard deadlines: Sectigo February 10, 2027. DigiCert March 1, 2027. Chrome Root Program March 15, 2027. After these dates, no public CA may issue SSL/TLS certificates containing the Client Authentication Extended Key Usage (EKU). Organizations using public SSL certificates for mutual TLS, VPN authentication, RADIUS/802.1X, or device authentication must migrate to private CA-issued certificates before these dates.

What Is Happening and Why

Public SSL/TLS certificates have historically been issued with two Extended Key Usage values: serverAuth (for HTTPS web server identity) and clientAuth (for authenticating clients to servers). This dual-purpose configuration was convenient but technically inappropriate: public CAs are included in browser trust stores to validate web servers, not to validate internal client identities.

Google’s Chrome Root Program Policy 1.6 mandates that certificate hierarchies included in Chrome’s trust store must be dedicated solely to TLS server authentication. This requirement propagates to all certificate authorities in Chrome’s root program. Public CAs cannot remain in Chrome’s trust store while continuing to issue certificates that include Client Authentication EKU after the March 15, 2027 deadline.

The result: every public CA is removing Client Authentication EKU from their SSL/TLS certificates on a CA-specific schedule, all converging before March 15, 2027. This is not a choice individual CAs are making independently. It is a requirement of the root store governance that makes their certificates trusted in Chrome, Firefox, Safari, and Edge.

The Precise Timeline: CA by CA

Existing certificates already issued before each CA’s cutoff date retain their Client Authentication EKU and remain trusted until they expire. Only new issuances and reissuances after the cutoff date lack it. With 199-day maximum certificate validity (the current standard as of March 2026), all certificates in circulation will lack Client Auth EKU within 199 days of the change. At 47-day validity (effective 2029), this transition completes within 47 days.

What Systems Are Affected

This change affects any organization using public SSL/TLS certificates for purposes other than HTTPS web server authentication. The systems that commonly use the Client Authentication EKU in public TLS certificates:

• VPN authentication: OpenVPN, Cisco AnyConnect, Fortinet SSL VPN, and similar VPN solutions that accept client certificates for user or device authentication at VPN login. If the client certificate is a public SSL certificate (ordered from Sectigo, DigiCert, or any public CA), it will no longer include Client Authentication EKU after the CA’s hard deadline.
• Mutual TLS (mTLS) in APIs and microservices: if the certificate used for the client side of an mTLS connection is a public TLS certificate, it will fail mTLS validation after the hard deadline. This affects API gateway configurations, service mesh setups (Istio, Linkerd), and any server-to-server authentication using public certificates.
• RDP Gateway: Windows Remote Desktop Gateway can be configured to require a certificate containing Client Authentication EKU for both server and client roles. Public certificates serving dual roles will break.
• Exchange Server internal connections: some Exchange Server configurations use the Client Authentication EKU for internal server-to-server authentication. Public certificates in these configurations are affected.
• RADIUS/802.1X network authentication via EAP-TLS: network authentication using EAP-TLS where the server certificate also serves as client identity. Affects Wi-Fi onboarding systems and wired network authentication configurations using public certificates.
• Cisco Expressway (documented real-world failure): Cisco’s Expressway collaboration platform uses Client Authentication EKU for Mobile and Remote Access (MRA). Organizations have reported Expressway rejecting connections after Sectigo certificates renewed without the Client Authentication EKU. Cisco issued a Field Notice; the resolution requires either migrating to private CA certificates or obtaining certificates from a CA that still includes the EKU before the hard deadline.

The population of affected organizations is substantially larger than most IT teams realize. Organizations that have been obtaining public TLS certificates for years and using them for client authentication because it was convenient and automated are now in the affected group. The key question: look at any internal system that uses certificate-based authentication and ask whether those certificates come from a public CA. If yes, plan a migration.

What Is Not Affected

• Standard HTTPS web servers: the only purpose of a web server’s public SSL certificate is server authentication. Web servers are completely unaffected by this change.
• Certificates already issued before each CA’s cutoff: these retain their EKU until they expire.
• S/MIME certificates: Sectigo’s FAQ explicitly states that S/MIME multipurpose certificates continue to support the Client Authentication EKU. This change applies only to SSL/TLS certificates.
• Private CA-issued certificates: private CA certificates are not in Chrome’s root program and are not subject to the Chrome Root Program Policy 1.6 requirement. Private CA certificates can include any EKU the issuing organization specifies.

How to Identify Affected Certificates in Your Infrastructure

Check whether a specific certificate contains the Client Authentication EKU:

openssl x509 -in certificate.pem -noout -text | grep -A3 ‘Extended Key Usage’

A certificate with both EKUs shows:

X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

A certificate with only serverAuth (post-deadline compliance) shows:

X509v3 Extended Key Usage:

TLS Web Server Authentication

For checking a live server’s certificate:

openssl s_client -connect yourdomain.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -A3 ‘Extended Key Usage’

Audit all certificates in your infrastructure that contain ‘TLS Web Client Authentication’ in their EKU. Each one that was issued by a public CA needs to be replaced before that CA’s hard deadline.

What to Replace Public CA Client Certificates With

Option 1: Private CA (on-premises)

A private certificate authority operates under the organization’s own control and is not part of any browser root program. Private CAs can issue certificates with any EKU combination, on any schedule, without public CA policy restrictions.

• Microsoft Active Directory Certificate Services (AD CS): included in Windows Server. Integrates with Active Directory for auto-enrollment of device and user certificates. Appropriate for organizations with Windows infrastructure.
• EJBCA (Enterprise JavaBeans Certificate Authority): open-source CA with enterprise features. On-premises deployment. Widely used in regulated industries.
• HashiCorp Vault PKI Secrets Engine: Vault’s PKI engine provides a CA API for automated certificate issuance in DevOps environments. Certificates can include Client Authentication EKU.
• OpenSSL CA: a simple private CA can be built with OpenSSL for small-scale deployments where central management infrastructure is not needed. Each certificate must be added individually as trusted on receiving systems.

Option 2: Managed Private CA (hosted)

For organizations that want the flexibility of a private CA without operating CA infrastructure:

• Sectigo Private CA: Sectigo offers private CA services that support Client Authentication EKU. This is the migration path Sectigo recommends to affected customers of their public CA services.
• DigiCert ONE: DigiCert’s unified platform includes private CA capabilities. Also offers DigiCert X9 PKI (based on ASC X9 Certificate Policy) which supports both Server Authentication and Client Authentication.
• AWS Private Certificate Authority: managed private CA service for AWS environments. Supports custom certificate profiles including Client Authentication EKU.
• GlobalSign Atlas: GlobalSign’s managed PKI platform for enterprise certificate management including private CA services.

Option 3: S/MIME Multipurpose Certificates for Specific Use Cases

Sectigo’s S/MIME multipurpose certificates continue to support the Client Authentication EKU after February 2027. For organizations using public certificates primarily for user identity authentication in S/MIME email contexts where the same certificate is also used for client authentication, S/MIME certificates remain available.

This option is limited: S/MIME multipurpose certificates are not appropriate as general-purpose TLS client certificates for VPN or mTLS use cases. They are designed for email contexts with client authentication as a secondary use.

Migration Planning Steps

• Step 1: Audit all certificates in your infrastructure for Client Authentication EKU using the openssl command above. Build an inventory of affected certificates with their CA, expiry dates, and the systems that use them.
• Step 2: Identify which replacement path applies to each use case: Windows AD CS for domain-joined devices and users; AWS Private CA for cloud-native services; Sectigo or DigiCert managed private CA for enterprise environments without existing private CA infrastructure.
• Step 3: Deploy the replacement private CA infrastructure. For AD CS, this typically requires standing up a Root CA and one or more Subordinate CAs. For managed private CA, this requires an account setup and certificate profile configuration.
• Step 4: Issue replacement certificates from the private CA for each affected system. Configure each system to trust the private CA’s root certificate.
• Step 5: Test each system with the private CA-issued certificate before decommissioning the public CA certificate.
• Step 6: Complete migration for all affected systems before Sectigo’s February 10, 2027 deadline or before the relevant CA’s hard deadline for certificates currently in use.

The February 10, 2027 Sectigo hard deadline is for new issuances. If a certificate issued before the deadline is still within its validity period, it retains the Client Authentication EKU until it expires. However, any renewal or reissuance after October 7, 2025 (the default-change date) requires explicitly requesting the EKU, and after February 10, 2027, requesting it is no longer possible. Plan migration completion before February 10, 2027 for organizations using Sectigo, or March 1, 2027 for DigiCert.

Frequently Asked Questions

Will our existing public SSL certificates stop working for client authentication before they expire?

No. Certificates already issued before each CA’s cutoff date retain their Client Authentication EKU and remain trusted until their natural expiry date. The change affects only new issuances and reissuances after the cutoff date. However, with 199-day maximum certificate validity (from March 2026), any certificate that needs renewal after February 10, 2027 cannot be reissued with Client Authentication EKU from Sectigo. Plan migration to ensure all affected systems have private CA certificates before their current certificates expire.

Our Cisco Expressway uses public Sectigo certificates for MRA. What do we do?

This is a documented and active issue. Cisco has issued guidance in response to Expressway rejecting connections after certificates renewed without the Client Authentication EKU. The resolution requires either: (1) migrating Expressway to use private CA-issued certificates with Client Authentication EKU, which requires configuring Cisco Unified Communications Manager and Expressway to trust the private CA’s root; or (2) while still possible, reissuing the Expressway certificate explicitly requesting the Client Authentication EKU before the February 10, 2027 Sectigo hard deadline. Option 2 is a temporary measure that postpones but does not resolve the migration requirement. Contact your Cisco TAC representative for environment-specific guidance.

Does this affect certificates used for code signing or S/MIME email?

No. Code signing certificates have their own certificate profiles and are issued separately from SSL/TLS certificates. S/MIME multipurpose certificates are explicitly confirmed by Sectigo to continue supporting the Client Authentication EKU. This change applies specifically to certificates issued under public SSL/TLS certificate hierarchies that are in browser root programs subject to Chrome Root Program Policy 1.6.