How do I manage Chrome’s clientAuth deprecation for AWS Certificate Manager (ACM) certificates?

Overview

Starting April 13, 2026, Google Chrome will stop trusting public TLS certificates that include the clientAuth Extended Key Usage (EKU). This change affects all public Certificate Authorities (CAs) trusted by Chrome — including those used by SaaS providers.

For AWS customers using AWS Certificate Manager (ACM) to manage public non-AWS TLS certificates, this change can disrupt certificate import or replacement pipelines, particularly in mutual TLS (mTLS) or client certificate authentication scenarios. This article explains why this issue occurs, how to addressed it, and best practices to ensure business continuity.

---

Root Causes

The Chrome clientAuth deprecation impacts ACM customers due to several factors:

1. Certificate Structure Changes –
   ACM historically treated removal of the clientAuth EKU as a structural change, blocking direct certificate replacement during import or rotation.

2. Automation Pipeline Risks –
   Certificate import or renewal automation may fail if the new certificate excludes clientAuth while the old one included it.

3. mTLS Dependencies –
   Workloads relying on clientAuth (e.g., SIP, BYOC, or API endpoints) may experience TLS handshake failures if not updated to serverAuth-only certificates or private PKIs.

4. Industry-Wide Impact –
   The deprecation affects all public CAs, requiring updates to trust stores and validation logic across customer environments.

---

Resolution

Follow these steps to mitigate the impact of Chrome’s clientAuth deprecation on ACM-managed certificates.

Step 1: Identify Impacted Certificates

Use the ACM API or AWS CLI to detect certificates containing both serverAuth and clientAuth EKUs:

aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn' --region <region>

For each certificate, check EKU details:

aws acm describe-certificate --certificate-arn <arn> --query 'Certificate.ExtendedKeyUsages' --region <region>

Example output:

[
  {"Name": "TLS_WEB_SERVER_AUTHENTICATION", "OID": "1.3.6.1.5.5.7.3.1"},
  {"Name": "TLS_WEB_CLIENT_AUTHENTICATION", "OID": "1.3.6.1.5.5.7.3.2"}
]

Identify certificates containing TLS_WEB_CLIENT_AUTHENTICATION for remediation.

---

Step 2: Update Automation Pipelines

Ensure your import and rotation pipelines are compatible with serverAuth-only certificates.

• Test imports using new certificates without clientAuth EKU.
• Update automation scripts to gracefully handle EKU changes.
• Validate in a non-production environment before rollout.

Example:

aws acm import-certificate \
  --certificate file://cert.pem \
  --private-key file://key.pem \
  --certificate-chain file://chain.pem \
  --region <region>

---

Step 3: Migrate mTLS to Private PKIs

For workloads using mTLS, transition to private CAs to avoid public CA restrictions.

• Use ACM Private CA, Google CAS, or an in-house CA.
• Example – create a private CA in ACM:

aws acm-pca create-certificate-authority \
  --certificate-authority-configuration '{"KeyAlgorithm":"RSA_2048","SigningAlgorithm":"SHA256WITHRSA","Subject":{"CommonName":"MyPrivateCA"}}' \
  --region <region>

Issue private certificates for mTLS and update trust stores accordingly.

---

Step 4: Update Trust Stores and Validation Logic

Ensure internal systems (APIs, SIP endpoints, etc.) accept serverAuth-only certificates.

• Update trust stores to include new chains.
• Test connectivity to confirm successful TLS handshakes.
• Monitor Chrome Root Program updates to stay compliant.

---

Step 5: Monitor and Communicate Timeline

• Engage customers by Q1 2026 to complete migrations before Chrome’s June 15, 2026 enforcement.
• Track ACM updates using the AWS Health Dashboard:

aws health describe-events --filter '{"services":["ACM"]}' --region us-east-1

---

Additional Recommendations

• Leverage ACM’s Updated Behavior: As of October 22, 2025, ACM no longer requires allowlisting for importing public certificates that omit clientAuth. Review the latest ACM documentation for compatibility.

• Test Alternative CAs: If a non-AWS CA fails import, test using other public or private CAs.

• Engage AWS Support: For complex mTLS setups, engage your AWS TAM or AWS Support for tailored guidance.

• Use Temporary Workarounds (Pre-Oct 2025): If immediate rotation fails, request temporary allowlisting or delay rotation until pipelines are updated.

---

Customer Value

• Business Continuity: Prevents TLS handshake failures for workloads like SIP, BYOC, and APIs.

• Operational Readiness: Aligns certificate practices with evolving CA and browser standards.

• Reduced Manual Work: Uses ACM’s updated automation for seamless certificate imports.

• Improved Security: Promotes private PKI adoption for secure mTLS operations.

---

Related Resources

• Google Chrome Root Program Update: https://pki.goog/updates/may2025-clientauth.html
• ACM Documentation History: https://docs.aws.amazon.com/acm/latest/userguide/dochistory.html
• Prerequisites for importing ACM certificates: https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html
• AWS CLI Reference – acm list-certificates: https://docs.aws.amazon.com/cli/latest/reference/acm/list-certificates.html
• ACM Private CA User Guide: https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html