EKU Client Authentication - Impacts of its deletion from SSL server certificates
Until a few months ago, server certificates included two Extended Key Usages (EKUs) by default:
- Server Authentication
- Client Authentication
Following Google's policy change for its Chrome browser, prohibiting the use of the "Client Authentication" EKU for server certificates, certification authorities began issuing their certificates accordingly.
This development has highlighted several cases of application incompatibilities, particularly in environments requiring mutual authentication (mTLS).
Why is the "Client Authentication" EKU sometimes essential?
The "Client Authentication" EKU is required when a server certificate is also used for:
- mutual TLS authentication
- outbound application authentication
- secure communication between platforms (APIs, gateways, MFT tools, telephony, etc.)
Without this EKU, some applications reject the certificate.
Identified cases
Here is a non-exhaustive list of environments that may cause problems because they require a dual EKU:
- Microsoft ADFS
- Cisco VoIP / Jabber
- Microsoft RDS (Remote Desktop Services)
- Axway CFT
- Synchrony Gateway
- WAF and intermediate services sometimes require both EKUs
- SAP
What are the solutions?
Sectigo, PositiveSSL, and TBS X509 certificates will continue to include both EKUs until May 2026 (excluding QWAC certificates).
DigiCert, for its part, ceased issuing server certificates with dual EKUs in October 2025. However, it remains possible to obtain such a certificate through reissuance (DigiCert, Thawte, and Geotrust products). Note, however, that a certificate issued with both EKUs will not be valid beyond June 15, 2026; a certificate expiring after this date may be truncated without compensation.
After June 15, 2026, you will need to install two certificates on your systems: one with a "Server Authentication" EKU and the other with a "Client Authentication" EKU (mTLS certificates).