Do You Even Know If You Use Client Authentication Certificates?

What a "client authentication certificate" actually is

There is no separate certificate type called a client certificate. It's an ordinary X.509 certificate whose Extended Key Usage (EKU) extension asserts the client-authentication purpose. Two OIDs matter:

• Server authentication — 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth) — "this cert can identify a server," i.e. normal HTTPS.

• Client authentication — 1.3.6.1.5.5.7.3.2 (id-kp-clientAuth) — "this cert can identify a client," i.e. the machine or service presenting a certificate in an mTLS handshake.

The certificates at the center of the 2027 changes are dual-EKU certs — public TLS certificates that carry both purposes. For years, most public CAs added clientAuth by default, so a cert someone requested to serve a website has quietly been usable as a client identity too. That is exactly what the CA/Browser Forum and the Chrome Root Program are ending: public TLS certificates are being restricted to serverAuth only.

Why you probably don't know you use them

This was the point raised on the Root Causes podcast, and it's the failure pattern worth internalizing: teams confidently say "clientAuth deprecation won't affect us" — right up until something breaks. Three reasons the exposure stays invisible:

The deadlines that make this urgent

These update automatically from the FixMyCert Compliance Hub.

Step 1 — Inspect a single certificate

Start by learning to read the EKU on one cert. Given a PEM file, run:

openssl x509 -in cert.pem -noout -ext extendedKeyUsage

Example output:

X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

"TLS Web Client Authentication" in the output means the clientAuth EKU is present. On OpenSSL older than 1.1.1 (no -ext flag), fall back to:

openssl x509 -in cert.pem -noout -text | grep -A1 "Extended Key Usage"

A cert that shows only TLS Web Server Authentication is already serverAuth-only and safe. A cert showing both is a dual-EKU cert — flag it and find out whether the clientAuth purpose is actually used.

Step 2 — Check a live endpoint

You won't always have the file. Pull the leaf straight off a running service and inspect it in one pipe:

openssl s_client -connect gateway.example.com:443 -servername gateway.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext extendedKeyUsage

Point this at the endpoints that terminate mTLS — API gateways, partner-facing load balancers, mesh ingress — not just your public website. Remember that in mTLS the certificate that needs clientAuth is the one the client presents, so also check the certs your outbound services use when they connect to someone else.

Step 3 — Sweep a host's certificate files

On any Linux host, find PEMs that carry clientAuth without opening each one by hand:

for f in $(grep -rlE "BEGIN CERTIFICATE" /etc/ssl /etc/pki /opt 2>/dev/null); do
  if openssl x509 -in "$f" -noout -ext extendedKeyUsage 2>/dev/null | grep -q "Client Authentication"; then
    echo "clientAuth: $f"
  fi
done

On Windows or AD CS environments, query the machine store with PowerShell and match on the clientAuth OID (more robust than the friendly name):

Get-ChildItem Cert:\LocalMachine\My | Where-Object {
  $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.5.5.7.3.2'
} | Select-Object Subject, NotAfter, Thumbprint,
    @{n='Issuer';e={$_.Issuer}},
    @{n='EKU';e={($_.EnhancedKeyUsageList.FriendlyName) -join ', '}}

Step 4 — Inventory across the estate

Per-host sweeps don't scale to an enterprise. Use whichever of these you already have wired up:

Step 5 — Look where clientAuth actually hides

Discovery tools find certs; they don't tell you which ones are load-bearing for client identity. These are the places dual-use certs quietly do double duty:

For each hit, record the subject, issuer (which CA), expiry, and whether the clientAuth purpose is genuinely exercised.

Step 6 — Triage what you found

The fix itself — splitting dual-use certs and standing up private PKI for client identities — is its own project. Once you've built the inventory here, follow the deprecation and migration guides below.

Next steps

Find them now, while every affected cert is still valid and you're working from an inventory instead of an incident.