When Public Certificates Stop Carrying clientAuth - Where AWS Sends or Accepts Client Certificates, and What Each Path Says About Extended Key Usage

First Published: 2026-10-12
Last Updated: 2026-10-12

Publicly trusted certificate authorities (CAs) are increasingly limiting TLS certificates to server authentication only. The AWS Certificate Manager (ACM) user guide, on its ACM certificate concepts page, includes the following note:

Effective June 11, 2025 AWS Certificate Manager no longer issues certificates with the "TLS Web Client Authentication" (clientAuth) extended key usage (EKU) to align with new browser requirements for website certificates.

Extended Key Usage (EKU) is an X.509 extension that indicates how the certificate's public key can be used. The value clientAuth signifies that the key can be used for TLS client authentication, while serverAuth indicates that it can be used for TLS server authentication. Let's Encrypt also ceased issuing certificates with clientAuth on July 8, 2026. Section 1.3.2 of the Chrome Root Program Policy v1.8 requires that subscriber certificates issued on or after March 15, 2027, only indicate id-kp-serverAuth.

This trend is also affecting AWS itself. The AWS Key Management Service (AWS KMS) developer guide places the section on mutual TLS (mTLS) with external key store proxies under the heading mTLS authentication (deprecated), stating that AWS KMS can no longer obtain client certificates suitable for mTLS from Amazon Trust Services. Conversely, when reviewing the pages describing how AWS services validate client certificates, no statement about client certificate EKU could be found on the pages for Application Load Balancer, Amazon API Gateway (incoming requests), Amazon CloudFront (viewer mTLS), or AWS IoT Core.

This article lists the locations where AWS sends or accepts client certificates, detailing for each location what the associated documentation states regarding public CA certificates and Extended Key Usage (EKU), or noting when no such information is present. It also lists the dates determined by public CAs and root programs regarding clientAuth, categorized by source. Places where the sources disagree and places where no relevant statement could be found are presented with both statements and the verification date. The sources used for this analysis include AWS service user guides, developer guides, API references, What's New announcements, the AWS blog, FAQs, the Chrome Root Program Policy, the CA/Browser Forum's Baseline Requirements, and announcements from Let's Encrypt and Google Trust Services, as verified on October 12, 2026 (Section 1.3). This article does not create any AWS resources or issue any certificates. It does not recommend which CA to use or advise transitioning to AWS Private Certificate Authority.

Related articles on this site:

1. Public Certificates Are Losing clientAuth — Scope and Verification Date
2. How to Read the Tables — Who Handles It, What You Configure, and How You Can Check It
3. The Dates — Who Decided What About clientAuth, and When
4. Where AWS Sends Client Certificates
5. Where AWS Accepts Client Certificates
6. Where to Check the EKU of Your Own Certificates
7. One Example Outside AWS — The Client Certificate ChatGPT Presents to MCP Servers
8. Where the Sources Disagree and Where No Statement Was Found
9. About Replacements — One Line Only
10. Frequently Asked Questions about Public Certificates Losing clientAuth
11. Summary
12. References

1. Public Certificates Are Losing clientAuth — Scope and Verification Date

This section will first outline the changes that have occurred. Subsequently, it will define the scope covered by this article, the date of verification, the materials reviewed, and the terminology used within this article.

1.1 What Has Changed

The timing for the removal of clientAuth from publicly trusted certificates varies depending on the Certificate Authority (CA). ACM stopped issuing certificates with the clientAuth Extended Key Usage (EKU) as of June 11, 2025 (as documented in the ACM user guide). Let's Encrypt removed clientAuth from its default profile on February 11, 2026, and ended its temporary tlsclient profile, which still supported clientAuth, on July 8, 2026. Google Trust Services announced that it would begin rejecting requests for certificates indicating id-kp-clientAuth in two phases: the week of November 10, 2025, and the week of April 13, 2026.

The reason cited by each CA is a requirement within browser root programs. Section 1.3.2 of Chrome Root Program Policy v1.8 requires that subscriber certificates issued on or after March 15, 2027, include an extendedKeyUsage extension that only indicates id-kp-serverAuth. In contrast, CA/Browser Forum Baseline Requirements v2.3.1 designates id-kp-clientAuth for subscriber certificates as MAY. The policy requiring the removal of clientAuth originates from the root program policy, not the Baseline Requirements (Section 3).

These changes may affect the functionality that allows publicly trusted certificates to be used as client certificates. This article divides the areas within AWS where client certificates are used into two categories: locations where AWS sends certificates and locations where AWS accepts certificates. It then presents relevant documentation for each of these areas (Sections 4 and 5).

1.2 Scope of This Article, and What It Does Not Cover

This article will address the following:

The schedule determined by the public CA and root program regarding clientAuth, and the associated documentation (Section 3).
The locations where AWS presents client certificates, and the documentation for each location, which describes the public CA and EKU (Section 4).
The locations where AWS validates client certificates provided by users, and the documentation for each location, which describes the public CA and EKU (Section 5).
Locations where users can verify the EKU of their own certificates (Section 6).
One example outside of AWS: the client certificate presented by ChatGPT to the MCP server (Section 7).
Places where the sources disagree, and places where no statement was found (Section 8).

This article does not cover the following.

mTLS with Application Load Balancer and Private CA Design: This topic is covered in the existing AWS Private CA Hierarchy Design, specifically Section 7. This article only describes what the Application Load Balancer page says about public CAs and Extended Key Usage (EKU).
History of the Root Program and Schedule for Shortening Certificate Validity Periods: This is covered in the existing TLS Certificate Ecosystem History and Timeline. This article will only focus on the schedule related to clientAuth.
mTLS Modes and Common Usage with Elastic Load Balancing and API Gateway: Section 7.3 of the existing AWS Elastic Load Balancing Decision Guide and Section 7.4 of the Amazon API Gateway Decision Guide cover this topic.
Design of IAM Roles Anywhere: This is covered in the existing AWS IAM Inbound Workload Federation. This article will only include a short note on the trust anchor and EKU (Section 5.5).
Three Methods for Obtaining Public Certificates from ACM: This is covered in a companion article, How AWS Certificate Manager Issues Public Certificates.
Ending Email Validation for ACM: This is covered in a companion article, Moving AWS Certificate Manager Off Email Validation.
Regarding Mozilla, Apple, and Microsoft root programs, this article only reviewed the Chrome Root Program Policy.
This article does not cover the steps for configuring mTLS, a comparison of CAs, methods of certificate abuse, or pricing.

The AWS services mentioned in the table were verified against primary sources on October 12, 2026. This article does not cover all AWS services. For example, while Amazon MSK Replicator gained support for mTLS for replication from external Kafka clusters to MSK Express brokers on June 22, 2026 (as announced in "What's New"), this article has not read the statements in its developer guide and therefore does not include it in the tables.

1.3 Verification Date and Reviewed Materials

The information presented in this article was verified using the following materials on October 12, 2026.

ACM: User guide pages on certificate concepts, re-importing certificates, import prerequisites, certificate search, and document history. API reference for CertificateDetail, CertificateSummary, ExtendedKeyUsage, Filters, ListCertificates, SearchCertificates. ACM FAQ.
AWS KMS: Developer guide pages on controlling access to external key stores and the external key stores page, along with the document history. AWS KMS FAQ. Specifications for the GitHub External Key Store Proxy API (including the revision history for v1.0.5).
Amazon API Gateway: Developer guide pages on mTLS for REST APIs and HTTP APIs, authenticating backend client certificates, and using ACM certificates for backend mTLS. What's New (September 8, 2026).
Amazon CloudFront: Developer guide pages on mTLS for viewers and trust stores, mTLS for origins, certificate management, and enabling. CloudFront FAQ. What's New (November 24, 2025 and February 2, 2026). Article on mTLS for origins in the Networking & Content Delivery Blog.
Elastic Load Balancing: mTLS page in the Application Load Balancer user guide.
AWS IoT Core, IAM Roles Anywhere, Amazon MSK, AWS Lambda, Amazon MQ, AWS Client VPN, Amazon SES Mail Manager: Pages on authenticating client certificates in each guide. For AWS Client VPN, also reviewed the troubleshooting pages for macOS, Windows, and Linux clients.
AWS Private Certificate Authority: Pages on defining templates in the user guide, and the API reference for IssueCertificate.
Chrome Root Program Policy: Version 1.8 (Last updated: 2026-02-05) and archived version 1.7.
CA/Browser Forum: Version 2.3.1 of the Baseline Requirements (dated October 4, 2026).
Let's Encrypt: Blog post from May 14, 2025 (including an update from March 16, 2026) and the Upcoming Features page. The body of the blog post as of January 7, 2026, was read from an Internet Archive copy.
Google Trust Services: Page on Public Key Infrastructure updates (May 2025 - Client Authentication Certificates (clientAuth) Deprecation).
OpenAI: The "Authentication - Plugins" page of OpenAI Developers, and the two CA certificates distributed there.

The dates for AWS What's New are based on the date in the announcement's postDateTime. For CloudFront's origin mTLS What's New, the URL indicates January 2026, while the postDateTime is 2026-02-02T18:00:00Z. This article refers to February 2, 2026.

1.4 Words That Share the Same Spelling but Refer to Different Things

In this article, the same word is used to refer to different things. To avoid any misunderstanding, these distinctions are clarified first.

June 15, 2026 (three that this article distinguishes): (1) Section 4.2.2 of Chrome Root Program Policy v1.7 specifies the date from which newly issued subscriber certificates must only assert id-kp-serverAuth. In v1.8, the date of this clause changed to March 15, 2027. (2) June 15, 2026 also appears in Section 1.3.2 of v1.8, marking the date from which the Chrome Root Program begins to gradually exclude PKI hierarchies that do not meet the requirements. It is also the date from which subordinate CA certificates newly disclosed to CCADB must only indicate id-kp-serverAuth. (3) This is the date mentioned in the AWS KMS developer guide, stating that external key store proxies requiring mTLS will no longer be able to communicate with AWS KMS. Throughout this article, whenever the date June 15, 2026 is mentioned, the specific context of the date will be clarified.
Sending, Accepting: In this article, when AWS is described as "sending," it refers to AWS services acting as clients in a TLS connection and presenting a client certificate. The article will specify whether the certificate presented is AWS's own (e.g., AWS KMS) or one provided by the user (e.g., API Gateway, CloudFront, Lambda). When AWS is described as "accepting," it refers to AWS services acting as servers, validating the client certificate presented by the user's client.
Subscriber Certificate: In the context of the Chrome Root Program Policy and Baseline Requirements, this refers to the end-entity certificate issued by a CA to a user. It is used to distinguish these certificates from a CA's own certificates (root CA and subordinate CA certificates).
Client (three that this article distinguishes): This refers to three distinct entities: a TLS client, a client certificate, and an ACME client. When the term "client" is used in this article, it specifically refers to a TLS client.
Public Certificate: In this article, this refers to a certificate issued by a public CA that is trusted by browsers and other applications. When referring specifically to certificates issued by ACM, the term "ACM public certificate" will be used.
Trust Store: This refers to the collection of CA certificates used by features such as Application Load Balancer, API Gateway, CloudFront viewer, and Amazon SES Mail Manager to validate client certificates. The list of trusted roots in an operating system or browser is referred to as a "root store" in this article.
Validation: In this article, "validation" refers to the validation of the certificate path of a client certificate. It does not cover ACM domain validation.

2. How to Read the Tables — Who Handles It, What You Configure, and How You Can Check It

The tables in Sections 3 through 5 use the columns and terminology established in Section 2 of How AWS Certificate Manager Issues Public Certificates. This section will briefly outline the borrowed elements and define the additions made in this article.

2.1 Common Columns

The tables in Sections 3 through 5 share the following five columns:

Aspect: The item of the contract. In the schedule table, this describes what changes regarding clientAuth.
Handled By: Who handles that item (see Section 2.2).
What You Configure: What the user configures. If the user's configuration cannot be found in the documentation, write Nothing.
How You Can Check It: The type of location where the user can verify this, along with the specific name (see Section 2.3).
Where the Source Says So: The documentation that supports this row, indicated by the page title, API operation name, or data type name.

The tables in Sections 4 and 5 use a Path column instead of Aspect (see Section 2.4). In these two sections, Aspect refers to client certificate validation for every row.

2.2 `Handled By` Values

A companion article defined the following five values for the Handled By column. This article will also use these five values.

ACM: Handled by ACM.
You: Handled by the user.
Your ACME client: Handled by the user's ACME client. This value is not used in this article.
The certificate authority: Handled by the certificate authority (CA).
The source does not say.: The source material does not specify who is responsible.

This article uses three more values. These additions do not alter the meaning of the original five values.

The receiving service: Handled by the AWS service that validates the user's client certificate. Used in the table in Section 5.
The root program: Handled by the browser's root program. In this article, this refers to the Chrome Root Program.
The CA/Browser Forum: Handled by the CA/Browser Forum. This value was added by the companion article Moving AWS Certificate Manager Off Email Validation, and this article will use it with the same meaning. The CA/Browser Forum is an organization that defines Baseline Requirements for public CAs.

In the tables in Sections 4 and 5, the Handled By column indicates the entity responsible for validating the client certificate at that point in the process. Where AWS sends a certificate, the entity performing the validation is the user's server, so an English description of the role is added in parentheses after You. For example, You (your backend validates) indicates that the user's backend is performing the validation.

2.3 Types of `How You Can Check It`

The How You Can Check It column begins with one of the following types, followed by a specific name.

API field: Can be verified by examining a field in the API response.
API operation: Can be verified by examining the result of an API operation.
Console: Can be verified in the AWS Management Console.
CloudTrail management event: Can be verified by examining CloudTrail management events. Management events are recorded by default.
CloudTrail data event: Can be verified by examining CloudTrail data events. Data events are not recorded by default.
CloudWatch metric: Can be verified by examining CloudWatch metrics.
EventBridge event: Can be verified by examining Amazon EventBridge events.
Documentation only: A description exists in the documentation, but no location to verify it could be found.
Not found: No location or description could be found in the reviewed documentation.

In Sections 4 and 5, this column specifies where users can verify whether their certificate meets the requirements for that row. Documentation only and Not found do not indicate that there is no way to verify; the documentation and search terms used are detailed in Section 8.2.

2.4 Columns Added in This Article

This article adds the following five columns:

Path: Rows from Sections 4 and 5, describing the path where a client certificate is used. Write this in English, for example, AWS KMS to an XKS proxy.
Sends or Accepts: Indicates whether AWS sends or accepts the certificate along this path. The values are: AWS sends its own certificate (AWS services present their own client certificate), AWS sends your certificate (AWS services present a client certificate provided by the user), and AWS accepts your clients' certificates (AWS services validate client certificates presented by the user's clients).
Public CA Statement: Describes how the documentation refers to public CA certificates for the client certificate on this path. If not found, write Not found.
EKU Statement: Describes how the documentation references the EKU (Extended Key Usage) for the client certificate along this path. If not found, write Not found.
Source Date: Only included in the schedule table (Section 3.6) and the table of places where the sources disagree (Section 8.1). This column lists the name of the document and its date. For "What's New," use the postDateTime date. For blogs, use the publication date. For policies and Baseline Requirements, list the version and date. For user guides and FAQs, as the pages do not display dates, record the date you verified the information. A companion article, Moving AWS Certificate Manager Off Email Validation, added this column, and this article uses it with the same meaning.

2.5 Four Kinds of Statements — Requiring, Unusable, Discontinued, and Not Documented

This article sorts the statements in the sources into four kinds: requiring, unusable, discontinued, and not documented. Statements of different kinds are not described with the same wording.

Requiring: The documentation states that a client certificate with clientAuth is required. This applies to mTLS for CloudFront origins.
Unusable: The documentation states that a particular type of certificate cannot be used. This applies to mTLS for API Gateway backends, where ACM public certificates are not supported.
Discontinued: The documentation states that a previously available feature is no longer available. This applies to the statement that AWS KMS can no longer obtain client certificates suitable for mTLS from Amazon Trust Services.
Not Documented: No mention of EKU (Extended Key Usage) is found in the documentation. This applies to many subsections of Section 5. That no mention is found does not necessarily mean that the service either inspects or does not inspect EKU.

The documentation says that something stops working when public certificates lose clientAuth only at places of the first three kinds (one AWS Client VPN troubleshooting sentence is discussed separately in Section 5.7). This article does not state whether something works or does not work regarding the fourth category (not documented).

2.6 When the Source Does Not Say, and When the Sources Disagree

In the table cells, include only the information provided by the source or a summary of that information. If the source does not provide information for a particular cell, write either The source does not say. or Not found. Before adding either of those phrases, this article searches the full text of the source document, as well as links from that source, and other pages from the same provider. These other pages may include user guides, developer guides (specifically the mTLS pages), FAQs, blogs, "What's New" sections, document history, and API references. The searches use the subject of the row, as well as the terms EKU, extended key usage, clientAuth, client authentication, and public.

When the sources provide conflicting information, list both pieces of information, each with its source, without favoring either one. Use the phrase the sources disagree consistently for such cases. The disagreements this article lists are summarized in Section 8.1.

3. The Dates — Who Decided What About clientAuth, and When

This section lists those who set dates related to clientAuth and the documents that state them. The decision-makers fall into three categories: CAs (including ACM, Let's Encrypt, and Google Trust Services), the root program (Chrome Root Program), and the CA/Browser Forum. Figure 1 presents a timeline that combines the dates relevant to this section with two dates from Section 4.1 regarding AWS KMS, creating a single, unified timeline.

Who Stopped Issuing clientAuth, and When

3.1 ACM — June 11, 2025

The date when ACM stopped issuing certificates with the clientAuth Extended Key Usage (EKU) is documented in the ACM user guide, on the page describing certificate concepts. As noted at the beginning of this article, the original text states:

Effective June 11, 2025 AWS Certificate Manager no longer issues certificates with the "TLS Web Client Authentication" (clientAuth) extended key usage (EKU) to align with new browser requirements for website certificates.

The Amazon API Gateway developer guide, on the page describing the use of ACM certificates for backend mTLS, also mentions the same date. This page says public certificates.

Effective June 11, 2025, AWS Certificate Manager no longer issues public certificates with the clientAuth extended key usage (EKU).

The ACM user guide uses the term certificates, while the API Gateway page uses public certificates. No separate statement in the ACM user guide was found regarding the EKU of private certificates issued by ACM (Section 8.2).

The Document history page of the ACM user guide contains three entries related to this change:

July 3, 2025: Removed the reference to the TLS Web Client Authentication extension from the certificate examples.
July 23, 2025: Added a note to the certificate concepts page regarding changes to certificate issuance related to the TLS Web Client Authentication extension.
October 22, 2025: Modified the handling of certificate re-import (item 4 in Section 8.1).

No announcements regarding this change were found in the ACM What's New section or the ACM FAQ (Section 8.2). This article relies on the user guide note and the Document history for its information.

3.2 Let's Encrypt — February 11, 2026, and the tlsclient End Date That Moved Once

Let's Encrypt announced on its blog on May 14, 2025, that it would end issuing certificates with the clientAuth EKU (Extended Key Usage). The blog post detailed a transition process, stating that the tlsclient profile, which retained clientAuth for users requiring more time to migrate, would begin on October 1, 2025. As of October 12, 2026, the blog post stated the following:

February 11, 2026: the default classic ACME profile will no longer contain the Client Authentication EKU.

July 8, 2026: the tlsclient ACME profile will no longer be available and no further certificates with the Client Authentication EKU will be issued.

The classic profile is the default ACME profile, while tlsclient is a temporary profile designed to retain clientAuth for users who require a longer transition period.

The planned end date for tlsclient has been adjusted. A version of the blog post from January 7, 2026, archived on the Internet Archive, stated the following in the same section:

May 13, 2026: the tlsclient ACME profile will no longer be available and no further certificates with the Client Authentication EKU will be issued.

On March 16, 2026, the following addition was made to the beginning of the blog post:

Update March 16, 2026: Thanks to some timeline changes in the root program requirements, we have been able to push back the removal of the tlsclient profile slightly. If you are already using the tlsclient profile before May 13, 2026, now you will be able to continue to do so through July 8, 2026.

According to the addition, users who had been using tlsclient prior to May 13, 2026, became able to continue using it until July 8, 2026. The Let's Encrypt "Upcoming Features" page now lists the completed item as follows:

On February 11, 2026, we removed the “TLS Client Authentication” Extended Key Usage (EKU) from our default certificate profile. On July 8, 2026, we retired the temporary tlsclient profile, completing the removal.

The quotation marks are the curly quotation marks of the original.

3.3 Google Trust Services — Two Phases

Google Trust Services announced that it would change how it handles the clientAuth setting for public TLS certificates within its Public Key Infrastructure update page, in two phases.

Phase 1: Starting the week of Nov 10, 2025, CSRs asserting the id-kp-clientAuth EKU will be rejected, with the exception that: the id-kp-serverAuth and id-kp-clientAuth EKUs must be set in the CSR, and the clientAuth query parameter must be set in the directory URL.

Phase 2: Starting the week of Apr 13, 2026, CSRs asserting the id-kp-clientAuth EKU will be rejected, with no exceptions.

In Phase 1 (the week of November 10, 2025), only requests that meet specific criteria are accepted as exceptions. In Phase 2 (the week of April 13, 2026), these exceptions are no longer available. April 13, 2026, is the Google Trust Services date, not the Chrome Root Program Policy date. An AWS re:Post article states this date as a Chrome date. This article does not use re:Post articles as primary source material.

3.4 Chrome Root Program — The Subscriber Certificate Clause Moved from v1.7 (June 15, 2026) to v1.8 (March 15, 2027)

The Chrome Root Program Policy is based on the principle that the Chrome Root Store is used solely for authenticating servers via TLS. Section 1.3.2 (Promote use of Dedicated TLS Server Authentication PKI Hierarchies) of version 1.8 states:

The Chrome Root Store is solely relied upon for TLS server authentication in Chrome; it is not used for any other PKI use case (e.g., TLS client authentication, secure email, code-signing, etc.).

Regarding the Extended Key Usage (EKU) for subscriber certificates, Section 1.3.2 of version 1.8 states:

All corresponding subscriber certificates issued on or after March 15, 2027, MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

In the previous version, v1.7, the same clause was located in Section 4.2.2 (PKI Hierarchies included in the Chrome Root Store) and specified a date of June 15, 2026.

All corresponding unexpired and unrevoked subscriber certificates issued on or after June 15, 2026 MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

The v1.7 archive page states, Version 1.7 of the Chrome Root Program Policy was superseded by Version 1.8 on February 05, 2026. In version 1.8, the date for the subscriber certificate clause was changed from June 15, 2026, to March 15, 2027, and the section number was also changed from Section 4.2.2 to Section 1.3.2. The wording of the clause is also different; v1.7 specified unexpired and unrevoked subscriber certificates, while v1.8 does not include this limitation.

However, the date of June 15, 2026, still appears in version 1.8. It is used 7 times, with 4 instances within Section 1.3.2. The remaining 3 instances (in Sections 1.1.3, 1.2.1, and 1.3.4.1) relate to CA documentation, the number of root certificates, and clauses regarding CT logs, and do not involve clientAuth. Two specific sentences within Section 1.3.2 are worth noting:

Beginning June 15, 2026, the Chrome Root Program will phase-out PKI hierarchies found in violation of the below requirements.

if disclosed to the CCADB on or after June 15, 2026: include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

The first sentence refers to the date when the Chrome Root Program begins to phase out PKI hierarchies that do not meet the requirements. The second sentence concerns certificates for subordinate CAs, requiring that subordinate CA certificates disclosed on or after this date only indicate id-kp-serverAuth. Of the clauses quoted here, only the subscriber certificate clause was changed to March 15, 2027, in version 1.8. This article does not describe June 15, 2026, as an outdated date.

March 15, 2027, is a future date as of the verification date, and is the date specified in the policy document. The same section of version 1.8 contains the sentence that begins

To reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a multi-purpose root CA certificate

. This sentence continues by stating that, regarding CAs that submitted applications for alternative root certificate registration before June 15, 2026, the Chrome Root Store may, on a case-by-case basis, temporarily retain the multi-purpose root certificate; it is not a sentence that extends the subscriber certificate date.

3.5 Baseline Requirements Mark clientAuth as MAY

The CA/Browser Forum's Baseline Requirements, version 2.3.1 (the October 4, 2026 version), specifies the Extended Key Usage (EKU) for subscriber certificates in the table in Section 7.1.2.7.10.

| `id-kp-serverAuth`                 | 1.3.6.1.5.5.7.3.1       | MUST            |
| `id-kp-clientAuth`                 | 1.3.6.1.5.5.7.3.2       | MAY             |

The Baseline Requirements, in their version applicable on the verification date, do not prohibit the id-kp-clientAuth for subscriber certificates. The reason a public CA might choose to exclude clientAuth is not based on the Baseline Requirements, but rather on the policies of their root program. As justification, the ACM user guide cites new browser requirements, while Google Trust Services references Browser Root Program requirement changes. A Let's Encrypt blog post from May 14, 2025, explains the reasoning as follows:

This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs.

The reference to June 2026 in this passage refers to the date of Chrome's policies at the time the blog post was published (v1.6 was then current; the v1.7 clause in Section 3.4 kept the same date). The right single quotation mark is the curly one of the original.

3.6 The Schedule Table

The following table lists the dates for Section 3, organized by who decided each.

Aspect	Source Date	Handled By	What You Configure	How You Can Check It	Where the Source Says So
ACM does not issue certificates with `clientAuth` (from June 11, 2025).	ACM User Guide (checked 2026-10-12), Document history (2025-07-23)	`ACM`	`Nothing`	`API field`: `DescribeCertificate`'s `ExtendedKeyUsages` (Section 6.1)	AWS Certificate Manager concepts, Use your own ACM certificate for backend mutual TLS in API Gateway
Let's Encrypt removes `clientAuth` from the default `classic` profile (February 11, 2026).	Let's Encrypt blog (2025-05-14), Upcoming Features (checked 2026-10-12)	`The certificate authority`	`Nothing`	`Documentation only`: Completed items in Upcoming Features	Let's Encrypt blog, Upcoming Features
Let's Encrypt ends `tlsclient` (July 8, 2026, initially May 13, 2026).	Let's Encrypt blog (2025-05-14, updated 2026-03-16), Upcoming Features (checked 2026-10-12)	`The certificate authority`	`Nothing`	`Documentation only`: Completed items in Upcoming Features	Let's Encrypt blog, Upcoming Features
Google Trust Services announced that it would reject requests indicating `id-kp-clientAuth` (week of November 10, 2025 and week of April 13, 2026).	Google Trust Services Updates page (last updated 2026-04-07; checked 2026-10-12)	`The certificate authority`	`Nothing`	`Documentation only`: Phases section of the Updates page	May 2025 - Client Authentication Certificates (clientAuth) Deprecation
Subscriber certificates will only support `id-kp-serverAuth` (March 15, 2027, Section 1.3.2 of v1.8; June 15, 2026, Section 4.2.2 of v1.7).	Chrome Root Program Policy v1.8 (2026-02-05), v1.7 (2025-07-15)	`The root program (sets the rule), The certificate authority (complies)`	`Nothing`	`Documentation only`: Section 1.3.2 of the policy	Chrome Root Program Policy
Gradually phasing out PKI hierarchies that do not meet the requirements (Section 1.3.2 of v1.8, June 15, 2026).	Chrome Root Program Policy v1.8 (2026-02-05)	`The root program`	`Nothing`	`Documentation only`: Section 1.3.2 of the policy	Chrome Root Program Policy
Subscriber certificates' `id-kp-clientAuth` is `MAY`.	Baseline Requirements v2.3.1 (2026-10-04)	`The CA/Browser Forum`	`Nothing`	`Documentation only`: Table in Section 7.1.2.7.10	Baseline Requirements v2.3.1

4. Where AWS Sends Client Certificates

This section lists the AWS services that act as TLS clients and present client certificates. In AWS KMS, AWS itself provides the certificate. For API Gateway, CloudFront, and Lambda, the certificates are ones that you provide. Figure 2 provides a breakdown of the locations described in this section and Section 5, separating instances where AWS sends certificates and where it accepts them.

Where AWS Sends or Accepts Client Certificates

4.1 From AWS KMS to an External Key Store Proxy — AWS's Own Certificate

AWS KMS's external key store (XKS) feature allows key material to be stored with a key manager outside of AWS. AWS KMS communicates with that key manager through an external key store proxy (XKS proxy). The AWS KMS developer guide's page on controlling access to external key stores places the section on mTLS under the heading mTLS authentication (deprecated). The text within that section reads:

Prior versions of this guide mentioned mutual Transport Layer Security (mTLS) as an optional, secondary authentication mechanism to authenticate requests from AWS KMS. With mTLS, both parties (AWS KMS as client and the XKS proxy as server) communicating over a TLS channel use certificates to authenticate to each other.

According to this text, in mTLS, AWS KMS acts as the client, while the XKS proxy acts as the server. AWS KMS presents its own client certificate, and the user's XKS proxy validates it. The following text reads:

However, changes to the Chrome Root Program Policy (Section 4.2.2) prohibit publicly trusted root CAs included in the Chrome Root Store from issuing certificates with the clientAuth Extended Key Usage (EKU) extension after June 15th, 2026. As a result, AWS KMS can no longer obtain a client certificate suitable for mTLS from Amazon Trust Services. Any XKS proxy used to create a new external key store in AWS KMS after March 16th, 2026 must not require mTLS. After June 15th, 2026, any XKS proxy configured to require mTLS will be unable to communicate with AWS KMS. Customers must rely on SigV4 authentication to verify that requests originate from AWS KMS.

The AWS KMS developer guide specifies two dates. After March 16, 2026, XKS proxies used to create new external key stores must not require mTLS. After June 15, 2026, XKS proxies configured to require mTLS will not be able to communicate with AWS KMS. The latter date, June 15, 2026, is a date stated in the AWS KMS developer guide, corresponding to Section 1.4 (3). The version and section number of the Chrome Root Program Policy referenced in that section of the guide are addressed in item 1 of Section 8.1.

The revision history for the external key store specifications (External Key Store Proxy API specifications) also records this same change in version v1.0.5, dated March 9, 2026.

Version 1.0.5 (Mar 9, 2026):
    * Removed the recommendation for XKS proxies to support mTLS as a secondary authentication mechanism.

The section in the AWS KMS developer guide mentions SigV4 authentication as a means for users to verify that a request originated from AWS KMS. The AWS KMS FAQ states that AWS KMS authenticates the XKS proxy using server-side TLS certificates. The discussion of the XKS proxy's server certificate is separate from the clientAuth discussion presented in this article.

No record of this change to mTLS was found in the rows of the AWS KMS "Document history" shown on the verification date. No announcement of this change was found in AWS KMS's "What's New" either (Section 8.2).

4.2 From Amazon API Gateway to Your Backend — Your Certificate

With the "What's New" announcement of September 8, 2026, Amazon API Gateway REST APIs became able to present ACM certificates to backend integrations. The API Gateway developer guide describes this feature as follows:

With outbound mutual TLS (mTLS), API Gateway acts as a TLS client. It presents a client certificate to your backend server when it connects.

In this configuration, API Gateway acts as the client and presents a client certificate that the user prepared in ACM. The user's backend then validates that certificate. The page detailing the use of ACM certificates for backend mTLS includes the following note:

ACM public certificates are not supported for backend client authentication.

Effective June 11, 2025, AWS Certificate Manager no longer issues public certificates with the clientAuth extended key usage (EKU). This feature requires that EKU, so use a certificate that you import into ACM, or one issued through AWS Private Certificate Authority.

This note clarifies that ACM's public certificates cannot be used in this configuration. Instead, it says to use certificates imported into ACM or certificates issued through AWS Private Certificate Authority. The "What's New" announcement also states that users can either import certificates from an existing PKI into ACM or have certificates issued to them through AWS Private Certificate Authority.

On the same page, the table outlining certificate requirements states the following regarding Extended Key Usage (EKU):

Extended Key Usage (EKU)
If present, must include clientAuth. If absent, the certificate is accepted.

According to this table, certificates with EKU extensions must include the clientAuth value. Certificates without EKU extensions are also accepted. For this configuration, this article does not stop at saying that clientAuth is required; it also states that certificates without EKU extensions are accepted. No separate statement was found (Section 8.2) that addresses how imported certificates are handled when they are issued by a public Certificate Authority.

4.3 From Amazon CloudFront to Your Origin — Your Certificate

CloudFront introduced support for mTLS with origins in the "What's New" release on February 2, 2026. In this configuration, CloudFront acts as the client, presenting a client certificate imported into ACM by the user to the origin. The origin server then validates that certificate. The CloudFront developer guide, on the page regarding managing certificates for origin mTLS, states:

CloudFront origin mTLS requires client certificates with Extended Key Usage (EKU) for TLS Client Authentication. Due to this requirement, you must issue certificates from your Certificate Authority and import them into AWS Certificate Manager. ACM automatic certificate provisioning and renewal features are not available for origin mTLS client certificates.

This page specifies that the client certificate must include clientAuth. The "Certificate Requirements" section of the same page also states Extended Key Usage (required). The page lists two potential sources for the client certificate:

CloudFront origin mTLS supports client certificates from two sources: AWS Private Certificate Authority: You can issue certificates from AWS Private CA using certificate templates that include TLS Client Authentication in the Extended Key Usage field (such as the EndEntityClientAuthCertificate template).

Third-party private Certificate Authorities: You can also issue certificates from your existing private Certificate Authority infrastructure and import them into ACM.

The page identifies two potential sources: AWS Private Certificate Authority and the user's private CA, but does not explicitly mention public CAs.

The same page contains one sentence that references public CAs.

Your origin servers must present certificates from publicly trusted Certificate Authorities during the mutual TLS handshake.

This sentence concerns the server certificate presented by the origin server, not the client certificate presented by CloudFront. This article does not confuse the two.

Regarding the renewal of client certificates for this configuration, the sources disagree (Section 8.1, item 3). The developer guide states that ACM's automatic renewal feature cannot be used, and that users must monitor expiration dates and import renewed certificates into ACM. This differs from the information provided in the CloudFront FAQ and the Networking & Content Delivery Blog.

4.4 From AWS Lambda to a Kafka Cluster — Your Certificate

Lambda's event source mapping can connect to both Amazon MSK and self-managed Apache Kafka clusters using mTLS. In this configuration, Lambda acts as the client and presents a client certificate stored in an AWS Secrets Manager secret. The Kafka cluster then validates that certificate. The Lambda developer guide states the following regarding Amazon MSK:

The client certificate must be signed by a certificate authority (CA) in the server's trust store.

The page describing self-managed Kafka states, The client certificate must be signed by a CA in the server's trust store. No description regarding the client certificate's Extended Key Usage (EKU) or information about public CA certificates was found on either page (Section 8.2). Both pages mention public CAs only in the context of the server certificate presented by the Kafka cluster to Lambda.

4.5 The Table of Paths Where AWS Sends

The following table lists the four paths described in Section 4. In this table, the Aspect of each row is client certificate validation.

Path	Sends or Accepts	Public CA Statement	EKU Statement	Handled By	What You Configure	How You Can Check It	Where the Source Says So
`AWS KMS to an XKS proxy`	`AWS sends its own certificate`	AWS KMS is no longer able to obtain an mTLS-compatible client certificate from Amazon Trust Services.	Cites the Chrome policy change that prohibits publicly trusted root CAs in the Chrome Root Store from issuing certificates with the `clientAuth` EKU.	`You (your XKS proxy validates)`	Do not require mTLS. Rely on SigV4 authentication.	`Documentation only`: Section on `mTLS authentication (deprecated)`.	Control access to your external key store
`API Gateway REST API to your backend`	`AWS sends your certificate`	Public certificates from ACM cannot be used.	If the certificate has an EKU extension, it must include `clientAuth`. Otherwise, it is accepted.	`You (your backend validates)`	Select a certificate imported into ACM or issued by AWS Private Certificate Authority.	`API field`: `ExtendedKeyUsages` in `DescribeCertificate`.	Use your own ACM certificate for backend mutual TLS in API Gateway
`CloudFront to your origin`	`AWS sends your certificate`	The sources are AWS Private Certificate Authority and a private CA. Public CAs are not explicitly mentioned.	Requires `clientAuth`.	`You (your origin validates)`	Select a client certificate imported into ACM in your origin's configuration.	`Console`: List of mTLS certificates for your origin (Section 6.2).	Certificate management with AWS Certificate Manager, Enable origin mutual TLS for CloudFront distributions
`Lambda to a Kafka cluster`	`AWS sends your certificate`	`Not found`	`Not found`	`You (your Kafka cluster validates)`	Place the client certificate in a Secrets Manager secret and reference it in the event source mapping.	`Not found`	Configuring Amazon MSK cluster authentication methods in Lambda, Configuring cluster authentication methods in Lambda

5. Where AWS Accepts Client Certificates

This section lists the locations within AWS services where AWS acts as a TLS server and validates client certificates presented by users. For many of these locations, no description regarding the Extended Key Usage (EKU) of client certificates was found in the documentation. This article does not state that these services do not check the EKU, nor does it state that they work with certificates issued by public Certificate Authorities (CAs) (see Section 2.5).

5.1 Application Load Balancer

The Application Load Balancer user guide, on the mTLS page, describes the sources of client certificates to be validated as follows:

When you use this feature, the load balancer authenticates clients using certificates from third-party certificate authority (CA) or by using the AWS Private Certificate Authority (PCA), optionally, with revocation checks.

This page lists third-party CAs and AWS Private Certificate Authority, but does not specify whether they are public CAs. The certificate requirements section on the same page lists X.509v3, public key types, and signature algorithms, but does not mention EKU. The CA certificate example provided on the page shows the key usage extension, but does not include the EKU extension. The design of mTLS for Application Load Balancer is covered in Section 7 of the existing AWS Private CA Hierarchy Design.

5.2 Incoming Requests to API Gateway — Custom Domain mTLS

The API Gateway's REST API mTLS documentation, under the heading Configuring your truststore, describes the certificates of the Certificate Authority (CA) that should be placed in the truststore as follows.

API Gateway accepts client certificates issued by any CA present in the chain of trust. The certificates can be from public or private certificate authorities.

This sentence describes the trust store used when API Gateway validates the client certificate of the user's client, stating that it can accommodate both publicly trusted and privately managed certificate chains. The HTTP API's mTLS page also contains the same two sentences. A separate sentence on the REST API page, You can request a publicly trusted certificate directly from ACM or import public or self-signed certificates. refers to server certificates for custom domains and does not pertain to client certificates. No description regarding client certificate Extended Key Usage (EKU) was found on either the REST API or the HTTP API page (Section 8.2).

5.3 CloudFront Viewer

CloudFront introduced support for mTLS with the viewer on November 24, 2025. The developer guide's "Trust Store" page states the following:

Trust stores contain the root and intermediate CA certificates that form the chain of trust for authenticating client certificates.

None of the pages related to viewer mTLS (the viewer mTLS page, the "Trust Store" page, the "Validation Mode" page, or the certificate revocation page) was found to contain descriptions of the client certificate's EKU (Extended Key Usage) (see Section 8.2). The trust store page states that CloudFront supports certificates issued by both AWS Private Certificate Authority and third-party private Certificate Authorities, and it does not name public CAs. The existing AWS History and Timeline regarding Amazon CloudFront also lists viewer mTLS as being introduced on November 24, 2025.

5.4 AWS IoT Core

The AWS IoT Core developer guide, on the page detailing how to create custom client certificates, states:

AWS IoT supports client certificates signed by any root or intermediate certificate authorities (CA).

The page on X.509 client certificates states, AWS IoT authenticates client certificates using the TLS protocol's client authentication mode. No description regarding client certificate EKU (Extended Key Usage) or information about public CA (Certificate Authority) certificates was found on either page (see Section 8.2).

5.5 IAM Roles Anywhere

IAM Roles Anywhere is a feature that allows users to obtain temporary AWS credentials using X.509 certificates. It validates the certificates presented by user workloads against trust anchors. The getting started page of the IAM Roles Anywhere user guide states:

Certificates issued from public CAs cannot be used as trust anchors.

The "Trust Model" page specifies the certificate constraints for end-entity certificates, stating that The key usage MUST include Digital Signature. The constraints listed for end-entity certificates are four: X.509v3 compliance, the CA value for basic constraints, key usage, and signature algorithm. No Extended Key Usage (EKU) requirement was found (see Section 8.2). The design of IAM Roles Anywhere is covered in the existing AWS IAM Inbound Workload Federation.

5.6 Amazon MSK

The Amazon MSK developer guide states the following regarding TLS client authentication:

To use client authentication, you need an AWS Private CA.

Client authentication for Amazon MSK requires AWS Private Certificate Authority. No description regarding the Extended Key Usage (EKU) for client certificates was found on this page (Section 8.2).

5.7 Amazon MQ, AWS Client VPN, Amazon SES Mail Manager

The documentation for Amazon MQ and Amazon SES Mail Manager specifies that client certificates must be signed by a trusted Certificate Authority (CA) or a CA in the trust store. The AWS Client VPN Administrator Guide details conditions under which client certificates' CA must be uploaded to ACM.

Amazon MQ (RabbitMQ): With the "What's New" release of January 8, 2026, it added support for authentication using X.509 client certificates. The developer guide states, Client certificates must be signed by a trusted Certificate Authority (CA). No mention was found regarding EKU (Extended Key Usage) or public CAs.
Amazon SES Mail Manager: The developer guide, concerning mTLS ingress endpoints, states, Mail sent to your domain must come from clients that present a TLS client certificate signed by one of the certificate authorities (CAs) in the ingress endpoint's trust store. No mention was found regarding EKU or public CAs.
AWS Client VPN: The Administrator Guide's section on mutual authentication states that you only need to upload client certificates to ACM when the CA for the client certificate differs from the CA for the server certificate. The same page says that certificates must adhere to RFC 5280, including the Certificate Extensions specified in section 4.2 of the memo, but does not name EKU. No mention of EKU or public CAs was found in the Administrator Guide.

Among the pages this article read, AWS Client VPN has only one sentence that mentions EKU. On the macOS client troubleshooting page, in the Extended key usage (EKU) section, the cause of connection failures is described as follows:

The server authentication succeeded. However, the client authentication fails because the client certificate has the extended key usage (EKU) field enabled for server authentication.

The suggested solution indicates that users should verify they are using the correct client certificate and key. The text notes that using the server certificate instead of the client certificate can trigger this error. This is one example on the macOS client troubleshooting page; the word EKU was not found in the troubleshooting pages for Windows and Linux clients. Based on this single sentence, this article does not state that AWS Client VPN requires clientAuth for client certificates.

5.8 The Tables of Paths Where AWS Accepts

The following two tables list the paths described in Section 5. In these tables, the Aspect of each row is the validation performed on the client certificate, and the Sends or Accepts column indicates that AWS accepts your clients' certificates. The first table lists the endpoints that receive requests via HTTP and MQTT.

Path	Sends or Accepts	Public CA Statement	EKU Statement	Handled By	What You Configure	How You Can Check It	Where the Source Says So
`Clients to an Application Load Balancer`	`AWS accepts your clients' certificates`	A third-party CA or AWS Private Certificate Authority. Does not specify whether it must be a public CA.	`Not found`	`The receiving service`	In verify mode, place a bundle of CA certificates in the trust store and associate it with the listener.	`Not found`	Mutual authentication with TLS in Application Load Balancer
`Clients to an API Gateway custom domain`	`AWS accepts your clients' certificates`	The trust store's CA can be either a public or private CA.	`Not found`	`The receiving service`	Specify the trust store located in Amazon S3 for the custom domain.	`Not found`	Require client certificates for your API with mutual TLS authentication in API Gateway, How to turn on mutual TLS authentication for your HTTP APIs in API Gateway
`Viewers to CloudFront`	`AWS accepts your clients' certificates`	AWS Private Certificate Authority and third-party private CAs are listed. Public CAs are not explicitly mentioned.	`Not found`	`The receiving service`	In required or optional mode, place a bundle of CA certificates in the trust store and associate it with the distribution.	`Not found`	Mutual TLS authentication with CloudFront (Viewer mTLS), Trust stores and certificate management
`Devices to AWS IoT Core`	`AWS accepts your clients' certificates`	Supports client certificates signed by any root CA or intermediate CA.	`Not found`	`The receiving service`	Register CA certificates or use certificates created by AWS IoT Core.	`Not found`	Create your own client certificates, X.509 client certificates

The second table lists credentials, messaging, VPN, and email receiving functions.

Path	Sends or Accepts	Public CA Statement	EKU Statement	Handled By	What You Configure	How You Can Check It	Where the Source Says So
`Workloads to IAM Roles Anywhere`	`AWS accepts your clients' certificates`	Certificates issued by a public CA cannot be used as trust anchors.	`Not found`. The key usage must include Digital Signature.	`The receiving service`	Register the CA as a trust anchor.	`Documentation only`: See the note on the getting started page.	Getting started with IAM Roles Anywhere, The IAM Roles Anywhere trust model
`Clients to Amazon MSK`	`AWS accepts your clients' certificates`	Requires an AWS Private Certificate Authority.	`Not found`	`The receiving service`	Specify an AWS Private Certificate Authority for client authentication in the cluster.	`Documentation only`: Client authentication page.	Mutual TLS client authentication for Amazon MSK
`Clients to Amazon MQ for RabbitMQ`	`AWS accepts your clients' certificates`	Certificates must be signed by a trusted CA.	`Not found`	`The receiving service`	Specify certificate settings, such as the CA certificate, using an ARN.	`Not found`	SSL certificate authentication for Amazon MQ for RabbitMQ
`Clients to AWS Client VPN`	`AWS accepts your clients' certificates`	`Not found`	The macOS troubleshooting page provides an example where authentication fails when using a client certificate with a server authentication EKU.	`The receiving service`	If the CA for the client certificate differs from the CA for the server certificate, upload it to ACM.	`Documentation only`: macOS troubleshooting page.	Mutual authentication in AWS Client VPN, Troubleshooting AWS Client VPN connections with macOS clients
`Mail clients to an SES Mail Manager ingress endpoint`	`AWS accepts your clients' certificates`	Certificates must be signed by a CA in the trust store.	`Not found`	`The receiving service`	Configure the trust store for the ingress endpoint.	`Not found`	Ingress endpoints

6. Where to Check the EKU of Your Own Certificates

This section identifies locations where users can verify whether their certificate includes the clientAuth Extended Key Usage (EKU). This article has not called these APIs.

6.1 ACM API Fields and Filtering

The ACM API returns the certificate's EKU (Extended Key Usage) as a field, and allows filtering based on EKU values. Both the DescribeCertificate API, which returns CertificateDetail, and the ListCertificates API, which returns CertificateSummary, include the ExtendedKeyUsages field. The API reference for CertificateDetail describes this field as Contains a list of Extended Key Usage X.509 v3 extension objects. The valid values for this field are listed under the Valid Values section of the ExtendedKeyUsage data type. Specifically, clientAuth corresponds to TLS_WEB_CLIENT_AUTHENTICATION, and serverAuth corresponds to TLS_WEB_SERVER_AUTHENTICATION.

Filtering is available through two operations. The Filters data type, passed to the Includes parameter of the ListCertificates API, allows you to specify EKU values using the extendedKeyUsage field. The SearchCertificates API returns the ExtendedKeyUsages in the results' X509Attributes. The certificate search section of the ACM user guide lists extended key usage as a filtering option based on X.509 attributes.

When filtering with ListCertificates, be aware of the default filtering conditions. The API reference for ListCertificates states that, by default, it does not return certificates with a CertificateKeyPairOrigin of ACME. Regarding the default key type, the body of the API reference states that only RSA_2048 certificates are returned, while the keyTypes field in the Filters data type lists both RSA_1024 and RSA_2048. In both cases, certificates using ECDSA key types are excluded from the default filtering. The description for keyTypes indicates that you must specify a key type to retrieve certificates using other types. The disagreement between the sources on the default key type is addressed in a companion article, How AWS Certificate Manager Issues Public Certificates.

These two fields and filtering options apply only to certificates held in ACM. For certificates outside of ACM, the user must inspect them using their own methods.

6.2 Configuring CloudFront Origins

The CloudFront Developer Guide, on the page detailing how to enable mTLS for origins, includes the following note in the console instructions:

(Note: Only client certificates with the EKU (Extended Key Usage) property set to "TLS Client Authentication" will be listed)

According to this note, the list of certificates available for selection when configuring origin mTLS will only display certificates that have the clientAuth attribute. The How You Can Check It entry in the CloudFront row of the table in Section 4.5 is based on this note.

6.3 Regarding the Values in the Sample Response

The certificate search page in the ACM user guide provides a sample response for SearchCertificates, which includes two values in ExtendedKeyUsages: TLS_WEB_SERVER_AUTHENTICATION and TLS_WEB_CLIENT_AUTHENTICATION. The issuer of this sample is Example CA. However, its Type is AMAZON_ISSUED, and its NotBefore of January 15, 2024, is earlier than June 11, 2025. This article does not present this sample as evidence that ACM public certificates can have clientAuth, nor does it count it as a place where the sources disagree.

7. One Example Outside AWS — The Client Certificate ChatGPT Presents to MCP Servers

Outside of AWS, one example of a system presenting a client certificate follows. The "Authentication - Plugins" page of OpenAI Developers states the following:

ChatGPT now presents an OpenAI-managed client certificate when establishing TLS connections to MCP servers. If your application validates client certificates, configure it to trust the OpenAI certificate chain below.

In this scenario, ChatGPT acts as the client, presenting a client certificate managed by OpenAI to an MCP server. The same page also notes that ChatGPT cannot present custom API keys or customer-provided mTLS certificates (nor can it present custom API keys or customer-provided mTLS certificates.).

The page distributes two CA certificates: OpenAI-Root-CA and OpenAI-Connectors-mTLS-CA. When examining both certificates using openssl x509, both show OpenAI as the issuer and lack the extendedKeyUsage extension. The page indicates that the MCP server should trust this chain, meaning ChatGPT's client certificate is part of OpenAI's CA hierarchy rather than a publicly trusted CA. The page also includes the instruction Verify the leaf certificate is valid for client authentication. The page does not say whether this is expressed through EKU. This article has not examined the actual leaf certificate presented by ChatGPT. The EKU (Extended Key Usage) of the leaf certificate has not been verified.

This example suggests that when the presenting party has its own CA hierarchy, it can create a configuration that is not affected by public CAs ending clientAuth. How the remote MCP server handles ChatGPT's client certificate is discussed in Section 5.5 of the existing Which MCP Clients a Remote MCP Server Lets In.

8. Where the Sources Disagree and Where No Statement Was Found

This section summarizes the places where the sources disagree and the statements not found among the documents referenced in Sections 3 through 7 of this article. This article does not claim that either document contains errors. All verification dates are October 12, 2026.

8.1 Where the Sources Disagree

The following table lists the places where the sources disagree.

#	Topic	One Source Says	Another Source Says	Source Date	Section
1	AWS KMS cites specific Chrome policy versions and sections	The AWS KMS developer guide and external key store specifications reference Section 4.2.2 of the Chrome Root Program Policy, stating that after June 15, 2026, public CAs will no longer be able to issue certificates with the `clientAuth` extension. The specification link points to an outdated URL from archive v1.7, which currently returns a 404 error.	The current version, v1.8, moves the subscriber certificate clause to Section 1.3.2, setting the date as March 15, 2027. Version 1.8 also uses June 15, 2026, for subordinate CA certificates and the start of phased exclusions.	AWS KMS developer guide (checked 2026-10-12), specification v1.0.5 (2026-03-09), Chrome Root Program Policy v1.8 (2026-02-05), v1.7 (2025-07-15)	Sections 4.1 and 3.4
2	XKS proxy and mTLS	The AWS KMS developer guide places the mTLS section under the heading `mTLS authentication (deprecated)`, stating that after June 15, 2026, XKS proxies requiring mTLS will no longer be able to communicate.	The AWS KMS FAQ states, `Optionally, your proxy can enable mutual TLS for additional assurance that it only accepts requests from AWS KMS.`	AWS KMS developer guide and FAQ (checked 2026-10-12)	Section 4.1
3	CloudFront origin mTLS client certificate renewal	The CloudFront developer guide states that ACM's automated issuance and renewal cannot be used for origin mTLS client certificates. Instead, users must monitor expiration dates and import renewed certificates into ACM, regardless of whether using AWS Private Certificate Authority or a third-party CA.	The CloudFront FAQ states that ACM handles certificate lifecycle management, including provisioning, renewal, and rotation. The Networking & Content Delivery Blog states that AWS Private Certificate Authority provides a lifecycle with automated renewal.	CloudFront developer guide and FAQ (checked 2026-10-12), Networking & Content Delivery Blog (2026-02-02)	Section 4.3
4	ACM certificate re-import and `clientAuth`	The certificate re-import page states that while the original certificate's EKU cannot be removed, the Client Authentication EKU can be removed as an exception. The import prerequisites page also states that a certificate that lacks the Client Authentication EKU, compared with the previous certificate, can be re-imported.	A document history entry from October 22, 2025, states, `ACM allows re-import of a certificate into the same ARN only when the ClientAuth EKU is missing from the previous certificate.` This suggests that re-import is only possible if the previous certificate did not have the `clientAuth` EKU.	Two pages from the ACM user guide (checked 2026-10-12), Document history (2025-10-22)	Section 3.1

Regarding item 1, the AWS KMS developer guide specifies two dates (March 16, 2026, and June 15, 2026) as decisions related to AWS KMS. This article does not state that AWS KMS dates have changed due to a change in the date of the subscriber certificate clause in Chrome's policy. No documentation was found specifying how long XKS mTLS could be used under version 1.8.

Regarding item 3, the CloudFront FAQ states that the source of client certificates can be either AWS Certificate Manager Private Certificate Authority or third-party private certificate authorities. AWS Certificate Manager Private Certificate Authority is the previous name for AWS Private Certificate Authority.

Regarding item 4, the re-import page continues,

If you require Client Authentication functionality, you must implement additional validations on your side, as ACM does not support rollback to previously imported certificates.

No documentation was found clarifying which behavior is intended, given that the two pages and the Document history read in opposite directions.

8.2 Where No Statement Was Found

The following table lists descriptions that could not be found on October 12, 2026, along with the locations and terms used in the search. The fact that a description is not found does not necessarily mean that the behavior it describes does not exist.

What Was Looked For	Where and How It Was Looked For	Result
Does the Application Load Balancer inspect the EKU (Extended Key Usage) of client certificates?	Searched pages related to mTLS, as well as configuration pages, using terms like `EKU`, `extended key usage`, `clientAuth`, `client authentication`, and `public`.	Not found. One result mentioned `client authentication` as a functional description.
Does API Gateway inspect the EKU of client certificates upon receiving requests?	Searched REST API and HTTP API mTLS pages using the same terms.	Not found.
Does CloudFront's viewer inspect the EKU of client certificates?	Searched pages related to viewer mTLS, trust stores, validation modes, certificate revocation checks, and FAQs using the same terms.	Not found.
Does AWS IoT Core inspect the EKU of client certificates?	Searched pages related to client certificates, custom client certificates, CA certificate management, and transport security using the same terms.	Not found.
Does IAM Roles Anywhere require an EKU?	Searched pages related to trust models, getting started, and authentication using the same terms.	Not found. However, there was a mention of requirements regarding key usage.
Do the developer guides for Amazon MSK, Amazon MQ, and Amazon SES Mail Manager, and the AWS Client VPN administrator guide, require an EKU?	Searched each page using the same terms.	Not found. AWS Client VPN had one instance on a troubleshooting page for macOS (Section 5.7) in the user guide.
EKU and public CA for mTLS client certificates from Lambda to Kafka.	Searched pages related to Lambda, Amazon MSK, and self-managed Kafka authentication using the same terms.	Not found. Public CA was mentioned in the context of server certificates.
ACM's announcement regarding the end of `clientAuth`.	Searched ACM's "What's New" using the API, and searched ACM's FAQs and certificate features pages using `clientAuth`, `client authentication`, and `EKU`.	Not found. Mentions were found in the user guide notes, document history, and on the API Gateway page.
EKU for private certificates issued by ACM and for exportable public certificates.	Searched ACM's user guide concepts, exportable certificates, features pages, and FAQs using the same terms.	Not found.
EKU for certificates issued by ACM before June 11, 2025, after renewal.	Searched ACM's user guide concepts, document history, and FAQs using `June 11, 2025`, `clientAuth`, and `renew`.	Not found. The note is a statement about issuance.
Handling of importing and using certificates with a public CA in API Gateway's backend.	Searched pages related to using ACM certificates in backend mTLS, backend authentication overview, "What's New," and the Compute Blog using `public` and `third-party`.	Not found. The Compute Blog mentioned the ability to import third-party certificates.
Announcement and record of changes for AWS KMS XKS mTLS.	Searched AWS KMS "What's New" and the document history, looking for mentions of `mTLS` and `external key store`.	Not found. Version 1.0.5 of the external key store specifications (March 9, 2026) contained a mention.
EKU for leaf certificates presented by ChatGPT.	Searched the "Authentication - Plugins" page of OpenAI Developers using `EKU` and `client authentication`.	No statement of the EKU itself was found. The page says `Verify the leaf certificate is valid for client authentication.` (Section 7). The article only referenced two CA certificates.

8.3 What Changes When the Sources Are Updated

The following statements in this article change when the sources are updated. At the time you read this article, the following pages need to be read again.

Chrome Root Program Policy (Section 3.4 and item 1 of Section 8.1 change when a version later than v1.8 is released.)
The page and FAQ regarding controlling access to external key stores with AWS KMS (Section 8.1, items 1 and 2).
The page and FAQ regarding managing mTLS certificates for CloudFront origins (Section 8.1, item 3).
The page regarding certificate re-import, the page regarding import prerequisites, and the Document history (Section 8.1, item 4).
Each page in Section 5 (The EKU Statement in the tables in Section 5.8 changes if descriptions regarding EKU are added.)

9. About Replacements — One Line Only

This article does not recommend a specific replacement. It names only one thing that appears in the sources. For the AWS Private Certificate Authority template EndEntityClientAuthCertificate/V1, the user guide states,

This template differs from the EndEntityCertificate only in the Extended key usage value, which restricts it to TLS web client authentication.

The EKU of EndEntityCertificate/V1 is both TLS web server authentication and TLS web client authentication, and it is the default template used when TemplateArn is not specified with IssueCertificate. The design of the AWS Private Certificate Authority hierarchy and templates is covered in the existing AWS Private CA Hierarchy Design.

10. Frequently Asked Questions about Public Certificates Losing clientAuth

This article aims to answer common questions that may arise when examining the system that utilizes client certificates.

Q1. Can ACM's public certificates be used as client certificates for mTLS on an Application Load Balancer?

ACM has not been issuing certificates with the clientAuth Extended Key Usage (EKU) since June 11, 2025 (Section 3.1). The Application Load Balancer mTLS documentation lists third-party CAs and AWS Private Certificate Authority as potential sources for client certificates, and no EKU statement was found on it (Section 5.1). This article does not verify whether Application Load Balancer's mTLS functionality works with certificates that do not have the clientAuth EKU. It neither confirms nor denies whether it will function.

Q2. What will happen to certificates issued by ACM before June 11, 2025?

The ACM user guide notes refer to certificates issued on or after June 11, 2025. No separate statement was found addressing the handling of certificates issued prior to that date, or the Extended Key Usages (EKUs) of certificates newly issued at renewal (Section 8.2). You can verify the EKU of your existing certificates using the ExtendedKeyUsages field in the ACM API (Section 6.1).

Q3. Chrome's policy date changed to March 15, 2027, so why does the AWS KMS XKS date remain June 15, 2026?

The AWS KMS developer guide references Section 4.2.2 of the Chrome Root Program Policy and sets two dates: March 16, 2026, and June 15, 2026 (Section 4.1). No documentation from AWS KMS was found that addresses how its dates are handled after the subscriber certificate date changed in v1.8. This article treats the AWS KMS date as a decision made by AWS KMS (see Section 8.1, item 1).

Q4. Did the CA/Browser Forum prohibit clientAuth?

Version 2.3.1 of the Baseline Requirements marks id-kp-clientAuth for subscriber certificates as MAY (Section 3.5). Section 1.3.2 of Chrome Root Program Policy v1.8 requires that clientAuth be removed from subscriber certificates issued on or after March 15, 2027.

Q5. If the documentation for the accepting side does not mention EKU at all, will it still work with a public CA's certificate?

That no such statement was found does not necessarily mean that the service is not examining EKU. Nor does it mean that it is. This article has not verified, at the endpoints in Section 5, whether publicly trusted CA certificates or certificates without clientAuth are accepted (see Section 2.5).

Q6. Is the Let's Encrypt tlsclient profile still functional?

The Let's Encrypt Upcoming Features page states that tlsclient was retired on July 8, 2026, and that certificates with the clientAuth Extended Key Usage (EKU) are no longer issued (Section 3.2).

Q7. Should you move to AWS Private Certificate Authority?

This article does not recommend a specific alternative. There are places in the sources that list AWS Private Certificate Authority as a source (for CloudFront origins, API Gateway backends, and Application Load Balancers), and other places that require AWS Private Certificate Authority (specifically, Amazon MSK) (see Sections 4 and 5). The design of AWS Private Certificate Authority is covered in the existing AWS Private CA Hierarchy Design.

11. Summary

The schedule varies depending on the Certificate Authority (CA): ACM has not issued certificates with clientAuth since June 11, 2025. Let's Encrypt removed it from the default profile on February 11, 2026, and ended tlsclient (originally scheduled for May 13, 2026) on July 8, 2026. Google Trust Services announced two phases, for the week of November 10, 2025, and the week of April 13, 2026.
The basis the CAs cite is root program policy: Section 1.3.2 of Chrome Root Program Policy v1.8 requires only id-kp-serverAuth for subscriber certificates issued on or after March 15, 2027. In v1.7, the date of this clause was June 15, 2026. Version 1.8 retains the June 15, 2026 date for subordinate CAs and the start of phased removal. Baseline Requirements v2.3.1 designates id-kp-clientAuth as MAY.
For three of the places where AWS sends client certificates, the documentation states an effect: AWS KMS can no longer obtain mTLS client certificates from Amazon Trust Services, and XKS mTLS is deprecated. API Gateway backends cannot use ACM's public certificates. CloudFront origins require clientAuth. No Extended Key Usage (EKU) description was found for the path from Lambda to Kafka.
For many of the places where AWS accepts client certificates, no EKU statement was found: No description of client certificate EKU was found in the documentation for Application Load Balancer, API Gateway (incoming), CloudFront (viewer), AWS IoT Core, Amazon MQ, and Amazon SES Mail Manager. IAM Roles Anywhere cannot use certificates from public CAs as trust anchors, and Amazon MSK requires AWS Private Certificate Authority. AWS Client VPN has only one example in the pages read, on a macOS troubleshooting page.
There are ways to verify this information: The ExtendedKeyUsages field in ACM's API, along with filtering options in ListCertificates and SearchCertificates, allows verification of the EKU for certificates held by ACM.
The sources disagree: The AWS KMS developer guide references section numbers and dates from Chrome's policy v1.7. The AWS KMS FAQ describes mTLS as an optional method. The sources also disagree on CloudFront origin renewal and ACM re-import. This article lists four places where the sources disagree and thirteen statements not found.

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi