Chrome will reject all public TLS certificates with ClientAuth EKU after this date.
ClientAuth EKU Migration Checklist
Complete migration checklist for organizations affected by the Chrome ClientAuth EKU removal. Covers discovery, planning, implementation, and production cutover phases.
When to Use
- • Using public CA certificates for mTLS
- • Server-to-server authentication with public certs
- • API gateways authenticating with public TLS certs
- • Partner B2B integrations using public certificates
Do NOT Use For
- • Standard HTTPS websites (ServerAuth only)
- • Already using Let's Encrypt (no ClientAuth)
- • Already using private/internal PKI
Quick Reference (TL;DR)
- Inventory all certificates using ClientAuth EKU from public CAs
- Select migration path: Private PKI, PKIaaS, X9 PKI, or separate certs
- Deploy new infrastructure and issue replacement certificates
- Test thoroughly, then execute production cutover before March 2027
1Prerequisites
Objective: Confirm scope and readiness before starting the migration
💡 If you only use public certificates for HTTPS (ServerAuth), you are NOT affected by this change
💡 Let's Encrypt certificates already exclude ClientAuth EKU and require no action
2Phase 1: Discovery
Objective: Build a complete inventory of affected certificates and dependencies
openssl x509 -in cert.pem -noout -text | grep -A 1 "Extended Key Usage"💡 Use Certificate Transparency logs (crt.sh) to discover certificates you may have missed
💡 Consider CLM tools (Venafi, Keyfactor, DigiCert) for automated discovery
3Phase 2: Planning
Objective: Select migration strategy and finalize technical architecture
💡 Private PKI offers most flexibility but requires operational expertise
💡 PKIaaS reduces operational burden but may have vendor lock-in considerations
💡 X9 PKI is specific to financial services and may have compliance benefits
4Phase 3: Implementation
Objective: Deploy new infrastructure and issue replacement certificates
openssl x509 -in new-cert.pem -noout -text | grep -A 3 "Extended Key Usage"💡 Always test trust store distribution before certificate deployment
💡 Maintain old certificates as fallback until cutover is validated
5Phase 4: Production Cutover
Objective: Execute production migration with minimal disruption
💡 Consider a phased rollout if you have multiple environments or regions
💡 Keep old certificates available for rollback for at least 1 week after cutover
6Final Verification
Objective: Confirm migration success and close out the project