The secure foundation of server-to-server communication is facing a mandatory industry shift: most major Public Certificate Authorities (CAs) are getting out of the business of issuing publicly trusted certificates for use in Client Authentication. This change is not a technological one, but rather a shift in responsibility, forcing organizations to adapt their Public Key Infrastructure (PKI) models.
If you are currently leveraging a Public CA to sign the client certificates used for Mutual TLS (mTLS) within an API Gateway environment like Apigee, you are now in a difficult position.
The Industry Shift: The Removal of the Client Authentication EKU
The source of this transition is a policy change driven by major CAs, including Sectigo and DigiCert, and supported by policy bodies like Google Chrome. These CAs are phasing out the Client Authentication Extended Key Usage (EKU) from publicly trusted SSL/TLS certificates.
The Technical Impact on mTLS
The removal of the EKU directly impacts the functionality of mTLS:
-
Critical Requirement: The Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2), often referred to as clientAuth, is a critical requirement for a digital certificate to be accepted by a server to authenticate a client during a TLS handshake.
-
Service Interruption Risk: If a client certificate is renewed or re-issued under these new rules without the necessary clientAuth EKU, the Apigee Gateway’s underlying ingress infrastructure (e.g., Envoy) will reject it during the TLS handshake. This results in dropped requests and a loss of service for those clients.
-
Mandatory Deadline: Reliance on root CAs to bind public keys with domain identifiers for client authentication will no longer be possible by mid-June 2026.
The Operational Burden: From Delegated Trust to Internal Management
Organizations essentially have two choices to maintain service continuity:
-
Rely on Self-Signed Certificates: Ask each API consumer to self-sign their certificates and manually add them to your trust store. Managing hundreds of individual self-signed certificates in your trust store is not recommended due to the significant operational burden and risk of service interruption.
-
Become your own Private CA: Establish a Private CA to take full control of the certificate policy and issue compliant Client Authentication certificates to your API consumers. This is the more strategic and scalable path.
This shift forces organizations to move from a system where trust was delegated to Public CAs to an internally managed Private PKI system, significantly increasing operational complexity.
| Aspect of Burden | Previous Reliance (Public CA Model) | New Requirement (Private PKI/Self-Signed) |
|---|---|---|
| Trust Store Scale | Apigee only needed to store a few Public CA root certificates. | If clients self-sign certificates, the Apigee trust store must include every client’s root, or worse, every leaf certificate. This is a major concern when dealing with a large volume of certificates. | ||
|---|---|---|---|---|
| Certificate Rotation | No change was needed on Apigee’s side when a client rotated keys, as the gateway trusted the Public CA’s constant root certificate. | Authentication must rely on the public key itself or the fingerprint of the entire leaf certificate. Since key rotation changes this fingerprint, it creates an additional change burden for Apigee with every key update. |
Intermediate Solution: Private PKI for mTLS Continuity
The most direct and immediate strategic path to guarantee mTLS continuity is to establish and manage a Private Certificate Authority (Private CA). This approach allows the enterprise to control the certificate policy and explicitly include the necessary clientAuth EKU.
Key to Sustainable Private PKI Implementation
To avoid the operational burden of managing thousands of individual client certificates, the Private CA must be set up to leverage trust chains:
-
Trust Store Optimization: The Apigee trust store should only contain the Private CA certificate (and any intermediate CAs), which are rotated far less frequently than client certificates.
-
CSR-based Issuance: The client creates a Certificate Signing Request (CSR) that the Private CA signs, issuing a compliant certificate.
-
Operational Benefit: With this approach, nothing changes on the Apigee side when individual client certificates expire and are renewed, as the gateway continues to trust the Private CA root certificate.
Accelerating Migration with Managed Services
Managed CA services dramatically simplify and secure the Private PKI process:
-
Google Cloud Certificate Authority Service (CAS): CAS is a highly scalable and available service designed to simplify and automate the management of private CAs. It allows a private CA to be set up in minutes. CAS is enterprise-ready, offering protection for private CA keys using FIPS 140-2 Level 3 validated Cloud HSMs.
-
CAS Documentation: For technical guidance on establishing a Private CA and creating certificates from a CSR, refer to the documentation samples.
-
Automation: Utilize standard ACME (RFC 8555) protocols and the Private CA’s RESTful APIs to automate the issuance, validation, and deployment of new client certificates. Solutions exist for various deployments, including cert-manager in Kubernetes clusters, and libraries for direct developer integration.
Long-Term Solution: Modernizing Authentication with DPoP
For organizations seeking maximum long-term operational efficiency and a modern security architecture, Demonstrating Proof of Possession (DPoP), defined in RFC 9449, is a powerful alternative.
DPoP shifts security from the TLS layer to the application layer. This approach eliminates the headaches of X.509 client certificate rotation by cryptographically binding an access token to a client’s private key using a specialized JSON Web Token (JWT). This can be a “preferred target state” using the change as an opportunity to “leap-frog” to a modern authorization model.
DPoP Implementation in Apigee
DPoP is fully implementable using Apigee’s existing policy toolkit. The flow involves three parties: the Presenter, the Issuer, and the Recipient.
| DPoP Step | Apigee Implementation Details | Operational Advantage | |||
|---|---|---|---|---|---|
| Issuance | The client sends a DPoP Proof JWT. Apigee uses the VerifyJWT Policy to validate the proof’s signature. Custom logic (JavaScript/Java Callout) extracts the client’s public key fingerprint (jkt) and injects it as a cnf.jkt claim into the Access Token being issued. | Custom Development Required: Requires development and maintenance of custom policies and logic. | |||
| Validation | The client sends the Access Token and a new DPoP Proof JWT with every request. A VerifyJWT Policy validates the DPoP Proof’s signature. Custom logic then compares the cnf.jkt from the token with the key fingerprint of the DPoP Proof JWT, proving key possession. | Maximum Long-Term Efficiency: The long-term gain is realized by eliminating all X.509 client certificate management and rotation. |
A GitHub sample demonstrates how Apigee can support a Proof-of-Possession (POP) exchange. Apigee POP Token Example
Summary
In summary, organizations must weigh the higher upfront development investment required for DPoP against the significant long-term operational savings it offers by moving away from the complexities inherent in the X.509 certificate ecosystem. The establishment of a Private CA provides the most straightforward path for immediate mTLS continuity.
Co-author: Ayo Salawu | @ayos
