Support Advisory: Public CA Client Authentication EKU changes - Impact to AppDynamics mTLS Configurations
Summary
Public Certificate Authorities are changing issuance practices for public TLS certificates that include the Client Authentication Extended Key Usage (EKU). DigiCert has announced that Client Authentication EKU stopped being included by default in public TLS certificates on October 1, 2025, and is planned to be fully removed from newly issued public TLS certificates on March 1, 2027.
This change is not expected to impact standard one-way SSL/TLS communication from AppDynamics Agents to the Controller. In standard one-way SSL/TLS, the Controller presents a server certificate and the agent validates it as a server certificate.
This change may impact AppDynamics configurations that use mutual TLS (mTLS), client certificate authentication, or certificates uploaded for outbound HTTPS request actions where AppDynamics must present a client certificate.
Affected Configurations
Affected AppDynamics Agents: Java Agent, Database Agent, Machine Agent, and .NET Agent for Windows
The following AppDynamics configurations may be impacted if they use a public CA-issued certificate as a client certificate and that renewed certificate no longer includes Client Authentication EKU:
- AppDynamics On-Premises mutual authentication between supported agents and the Controller
- .NET Agent for Windows mutual authentication using a configured client certificate thumbprint
- Java-based agent mutual authentication that uses configured client keystores, including Machine Agent and DB Agent configurations where SSL client authentication is enabled
- Controller HTTP Request Template / Alert and Respond mTLS configurations where the Controller presents a client certificate to an external endpoint
Configurations Not Affected
The following configurations are not expected to be impacted by the public CA Client Authentication EKU change:
- Standard AppDynamics Agent to Controller communication using one-way SSL/TLS
- AppDynamics Controller server certificates used only for HTTPS server authentication, provided they include Server Authentication EKU and otherwise meet trust and hostname requirements
- On-Premises deployments using private or internally issued certificates, provided the internal certificate template still includes the correct EKU for the intended use
- SaaS or On-Premises agent communication that does not use mutual authentication / mTLS
Impact
If a certificate used as an mTLS client certificate is renewed without Client Authentication EKU, mutual authentication may fail because the certificate is no longer valid for client authentication.
Possible symptoms include:
- Agent connection failures when mTLS or SSL client authentication is enabled
- Controller rejection of agent client certificates
- HTTP Request Template failures when mTLS is enabled for outbound webhook or request actions
- TLS handshake failures or certificate validation errors indicating the certificate is not valid for client authentication
Recommendation
The following recommendations are intended to minimize certificate renewal and connectivity risk by ensuring that client certificates are purpose-built and correctly validated. As a critical security measure, isolate certificate profiles by intended use and verify them before renewal.
- Conduct a thorough audit of all AppDynamics settings that utilize mTLS or client certificate authentication to identify which certificates are issued by a public CA.
- For mTLS client authentication, we recommend that you use one of the following certificate profiles:
- A private or internal PKI certificate profile specifically designed for client authentication.
- A certificate product or profile that explicitly supports Client Authentication Extended Key Usage (EKU).
- Distinct certificate profiles for server authentication versus client authentication.
- Do not reuse a renewed public TLS server certificate as an mTLS client certificate unless your issuing CA confirms that the certificate specifically includes the required Client Authentication EKU and is intended for client authentication purposes.
Workaround
If a renewed public certificate no longer includes Client Authentication EKU and is being used as an AppDynamics mTLS client certificate, replace it with a certificate that is valid for client authentication.
For On-Premises deployments, the preferred workaround is to issue the mTLS client certificate from a private or internal CA using a certificate template that includes Client Authentication EKU. The Controller truststore or relevant external endpoint truststore must trust the issuing CA chain.
For Controller HTTP Request Template mTLS, generate or upload a client certificate that includes Client Authentication EKU and is accepted by the target endpoint.
Resolution
No product code change is required for standard one-way SSL/TLS AppDynamics Agent to Controller communication.
References
- AppDynamics On-Premises mutual authentication
- AppDynamics .NET Agent private key and client certificate documentation
- AppDynamics .NET Agent SSL support
- AppDynamics HTTP Request Template mTLS documentation
- Splunk Platform advisory: third-party certificate authorities cease issuing certificates with serverAuth and clientAuth EKU extensions
- DigiCert notice: removing Client Authentication EKU from public TLS certificates
- Chrome Root Program policy
- RFC 5280 section 4.2.1.12: Extended Key Usage
Revision history
| Date | Status | Description |
|---|---|---|
| 2026-06-01 | Initial Publication | Initial AppDynamics support advisory |