Client Authentication Extended Key Usage (EKU)

Overview

Client Authentication Extended Key Usage (EKU) is a certificate attribute that allows an SSL/TLS certificate to be used for client authentication, most commonly in mutual TLS (mTLS) scenarios.

In mTLS, both sides authenticate each other:

• The server presents a server certificate
• The client application presents a client certificate containing the Client Authentication EKU

This is commonly used for:

• Secure API integrations
• Partner gateways
• Financial and insurance systems
• Zero-trust architectures

What Is Client Authentication EKU?

Extended Key Usage (EKU) defines what a certificate is allowed to be used for.

The Client Authentication EKU is identified as:

1.3.6.1.5.5.7.3.2  (Client Authentication)

A certificate containing this EKU can:

• Identify a client application
• Be presented during the TLS handshake
• Be validated by the remote server as a trusted client

Without this EKU, the certificate cannot be used for mTLS client authentication.

Industry Change: Public SSL Certificates No Longer Support Client Authentication EKU

Due to industry-wide security and browser root program changes, public Certificate Authorities no longer issue SSL/TLS certificates that include Client Authentication EKU.

This affects:

• Sectigo
• DigiCert
• RapidSSL
• Other publicly trusted CAs

As a result:

• Public website SSL certificates are now Server Authentication only
• Client Authentication EKU is no longer available in public SSL certificates
• IIS hosting providers cannot install or issue such certificates

This is expected behavior and not a hosting limitation.

Supported Alternative: Private PKI Client Certificates

For mTLS and client authentication, the supported solution is to use a Private PKI client certificate.

Key differences

How to Use a Private PKI Client Certificate on Shared IIS Hosting

On shared IIS servers:

• Certificates cannot be installed into the Windows certificate store
• IIS does not manage outbound client certificates

Instead, the certificate is used directly by the application.

Recommended Setup

1. Store the certificate securely

Upload the PFX file to a non-public folder such as:

/App_Data/cert.pfx

Ensure:

• The file is not web-accessible
• The password is stored securely (config file, environment variable, or secret store)

2. Load the certificate in application code

The application loads the certificate only when making outbound HTTPS calls.

Example: .NET / ASP.NET (HttpClient)

using System.Net.Http;
using System.Security.Cryptography.X509Certificates;
var certPath = Server.MapPath("~/App_Data/cert.pfx");
var certPassword = "your-pfx-password";
var clientCert = new X509Certificate2(
    certPath,
    certPassword,
    X509KeyStorageFlags.MachineKeySet
);
var handler = new HttpClientHandler();
handler.ClientCertificates.Add(clientCert);
using var client = new HttpClient(handler);
// Example API call
var response = await client.GetAsync("https://api.partner.com/endpoint");

This:

• Sends the client certificate during the TLS handshake
• Enables mTLS authentication
• Requires no IIS configuration

3. Partner establishes trust

The external system (e.g., API gateway):

• Registers the public portion of the certificate
• Trusts inbound requests signed by that certificate

Local “Not Trusted” warnings are expected for Private PKI certificates.

What You Do NOT Need to Do

• ❌ Do not install the certificate as a website SSL
• ❌ Do not add IIS bindings
• ❌ Do not replace your public HTTPS certificate
• ❌ Do not enable IIS client certificate authentication

Summary

• Client Authentication EKU enables mTLS client identity
• Public SSL certificates no longer support this EKU
• This is an industry-wide change
• Private PKI client certificates are the correct solution
• On shared IIS hosting, the certificate is loaded by application code
• IIS configuration is not required