This article explains how Symphony Messaging uses Mutual TLS (mTLS) for secure API communications, and details the upcoming industry changes regarding the deprecation of the Client Authentication Extended Key Usage (EKU) in public certificates, and provides the steps your organization needs to take to ensure continuous service.
In this article:
- What is the Client Authentication EKU?
- How Symphony Messaging API endpoints use Mutual TLS (mTLS)
- Symphony Messaging customers affected by Client Authentication EKU deprecation
- Alternative solutions and required customer actions
What is the Client Authentication EKU?
Extended Key Usage (EKU) is a certificate extension that explicitly defines what a certificate’s public key can be used for. The Client Authentication EKU (Object Identifier: 1.3.6.1.5.5.7.3.2) specifically designates a digital certificate for authenticating a client (such as your bot or device) to a server, a common requirement in mTLS.
Industry change: Client Authentication EKU deprecation
Historically, many public browser-trusted server TLS certificates included both the Server Authentication EKU and the Client Authentication EKU (dual-purpose certificates).
The security industry, led by the CA/B forum and major browser root programs (Google Chrome, Mozilla, Apple, Microsoft), is requiring the removal of the Client Authentication Extended Key Usage (EKU) from publicly trusted SSL/TLS certificates.
Why is this change happening?
The removal of the Client Authentication EKU is driven by security concerns and the need for clearer cryptographic roles. Public TLS certificates are intended strictly for server authentication on the open Internet. Allowing them to also contain the ClientAuth EKU creates a risk of misuse, misconfiguration, and policy violations, potentially facilitating unauthorized access or lateral movement.
This change enforces separation of trust roles, ensuring public server certificates are used only for verifying servers.
Timeline for EKU removal
Major Certificate Authorities (CAs) will begin phasing out the Client Authentication EKU from new public certificate issuance starting in September 2025, with a final cutoff scheduled for mid-2026. Please check your CA for their compliance timeline.
Note: Existing certificates will remain trusted until they expire.
How Symphony Messaging API endpoints use Mutual TLS (mTLS)
Symphony Messaging uses mTLS primarily to enable certificate-based authentication for bots connecting to Symphony Messaging. This mechanism ensures that only trusted clients (your bots) can communicate with our API endpoints.
Enhanced API Security via mTLS Architecture
-
Client validation: When your bot sends a request to the mTLS paths (such as /sessionauth/v1/authenticate or /keyauth/v1/authenticate), Symphony Messaging serves the server certificate, and then checks for the presence of a client certificate from the bot.
The Symphony Messaging API mTLS endpoint serves a certificate with the Server Authentication EKU, and expects in return a bot certificate with the Client Authentication EKU. - CA trust: Symphony Messaging validates the client certificate presented by the bot against the trusted Certificate Authorities (CAs) defined by the customer in the Symphony Messaging Admin and Compliance Portal (ACP).
Symphony Messaging customers affected by Client Authentication EKU deprecation
Symphony Messaging bots authenticating to the Symphony Messaging API via mTLS and presenting a client certificate from commonly issued browser-trusted TLS certificates are affected by the Client Authentication EKU deprecation. The current certificates remain valid. Please ask your CA about their timeline for compliance with the new Client Authentication EKU deprecation. When issuing new certificates, please check for the Client Authentication EKU in the certificate before installing into your bot.
Bots which present client certificates from a private PKI, managed PKI-as-a-Service, or non-browser server certificates, are not affected by this deprecation.
Alternative solutions and required customer actions
If your organization currently relies on publicly trusted, dual-purpose SSL/TLS certificates for bot mTLS, action is required before the deadlines. You must transition to issuing dedicated client certificates that explicitly include the Client Authentication EKU for bot authentication.
Alternative PKI (Public Key Infrastructure) solutions
Organizations requiring the Client Authentication EKU must adopt dedicated solutions:
Organizations requiring the Client Authentication EKU must adopt dedicated solutions:
Private Public Key Infrastructure (Private PKI): Running your own dedicated CA for internal use cases, allowing you to fully control EKU issuance.
PKI-as-a-Service: Leveraging a managed or cloud CA solution to issue specific client certificates with the required EKUs.
Sector-Specific Solutions (e.g., DigiCert X9 PKI): The DigiCert X9 PKI is a dedicated infrastructure designed for interoperability and flexibility in non-web browser scenarios, such as API gateways and host-to-host communications (mTLS). X9 PKI certificates are governed independently of the CA/B Forum and browser root programs and can contain both client and server authentication EKUs.
Required customer actions
Symphony’s mTLS solution for bots requires the customer to provide the necessary CA trust anchor via the Symphony Messaging Admin Portal. The primary action required on the customer side relates to ensuring the sourcing and issuance of their bot certificates comply with the new EKU requirements.
Step 1: Review your certificate inventory and usage
You must audit your current certificate inventory to determine which systems and bots rely on dual-use (server/client) certificates for client authentication. If your certificates are publicly issued and include the Client Authentication EKU, you must prepare to switch.
Step 2: Implement a dedicated client certificate issuance solution
Based on your needs, transition to a dedicated solution (Private PKI, PKI-as-a-Service, or X9 PKI) to issue client certificates specifically for your bots, ensuring these new certificates include the Client Authentication EKU.
Step 3: Configure CA in the Symphony Symphony Messaging Admin Portal
The process for enabling certificate authentication on Symphony Messaging remains centered on configuring your Certificate Authority (CA) in the Admin Portal:
Define your CA in the Admin Portal: The customer defines their CA (Certificate Authority) in the Admin Portal to enable certification authentication for bots.
Issue client certificates: The customer creates a service account in Symphony Messaging (for example, bot-test) and issues a new client certificate signed by the defined CA, ensuring the Common Name (CN) equals the name of the service account. This certificate must be a dedicated client certificate containing the Client Authentication EKU, sourced from your chosen compliant PKI solution.
Bot Connection: The customer's bot calls the Symphony Messaging API endpoint (such as https://vanity-api.symphony.com/keyauth) using this newly issued, compliant certificate.
Following these steps ensures that your bot authentication processes remain secure, functional, and compliant with evolving industry standards, minimizing any operational disruptions.