YorozuyaIT
Dev & Infrastructure

mTLS or Server-to-Server TLS Suddenly Fails After a Certificate Renewal? Public CAs Dropped Client Authentication

Written by the Yorozuya IT editorial team, based in Japan. Menus, apps, and rules change, so check the date.

Short answer

Everything worked on Monday. On Tuesday the renewal job ran, and now a partner's API gateway rejects your calls, your mail relay cannot authenticate, or two services stop talking. The logs say something like "unsupported certificate purpose" or "certificate not valid for client authentication". Nothing in your code changed. The certificate did.

What changed

A certificate carries a list of allowed uses called Extended Key Usage (EKU). For a public website certificate the important ones are:

For years, many public CAs put both on the same certificate. That let teams use one cheap certificate for HTTPS and for client authentication. The browser root programs now require TLS server certificates to carry only serverAuth, and CAs are following. Chrome's root program set a deadline for June 2026, Let's Encrypt stopped including clientAuth in its default profile in February 2026, and other CAs, as reported by industry writers, have final cutoffs in early 2027.

Before: dual-EKU certificate works in both roles. After renewal: serverAuth only, the client role is rejected. Plus CA cutoffs and the fix.

The server side keeps working, because the certificate still says serverAuth. Only the client role breaks, and it breaks at renewal, not on the announced date, which is why it feels random.

Check your certificate

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

A dual-purpose certificate shows:

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

A new server-only certificate shows only TLS Web Server Authentication. If you use that certificate as a client and the second item is missing, that is the cause.

For a live server:

echo | openssl s_client -connect host:443 -servername host 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Extended Key Usage"

Also look at the other side of the connection: a peer that "requires a client certificate" may verify the purpose, and that check is what fails.

Where it hurts

Fix options

  1. Use a private CA for client certificates. If both ends are under your control or by agreement, run a small internal CA and issue clientAuth certificates yourself. Tools such as step-ca or cfssl are built for this. This is the long-term answer: public CAs are meant for proving a server's identity to the public, not for identifying your clients.
  2. Buy client certificates from a CA that still issues them. Some CAs offer dedicated client authentication certificates, or kept dual use until their announced cutoff. This buys time, not a solution.
  3. Replace mTLS where you can. If the real need is "know who is calling", tokens, signed requests, or mTLS with a private CA can all do it.
  4. Separate roles. Where one certificate played both roles, use two: a public server certificate for HTTPS and a private client certificate for client authentication.

Ask your partner, if they run the verifier: they may be able to trust your private CA.

A short checklist

  1. Search your configs for ssl_verify_client, client_certificate, SSLVerifyClient, mutual TLS, and cert=/key= in client code.
  2. For every match, run the OpenSSL check above.
  3. List each system that uses a public certificate as a client.
  4. Move those to a private CA, and test with a server-only certificate before the next renewal.
  5. Subscribe to your CA's announcements for exact dates.

Sources

Dates differ between sources; confirm with your CA. Information as of November 5, 2026.

FAQ

Why did it stop working with no config change?

Your application did not change. The renewed certificate has a different set of allowed uses. Systems that require the clientAuth usage reject the new certificate.

What typically breaks?

Mutual TLS between services or partners, some server-to-server protocols that use one certificate in both roles (federation in some chat and mail systems), VPN and gateway logins, and appliances that present a public certificate as a client.

Are the cutoff dates consistent?

No. Sources disagree on some dates, for example for Let's Encrypt's opt-in client profile (May 13 or July 8, 2026), and other CAs announce their own dates. Check your CA's notice.

Can I just add clientAuth back?

Not on a publicly trusted server certificate once your CA stops issuing it. Use a certificate that is issued for client authentication instead.

Keep reading

Dev & Infrastructure4 min read

MySQL “Incorrect string value” for Emoji, Umlauts, or Japanese: Fix It with utf8mb4 (and Avoid the Collation Traps)

Error 1366 'Incorrect string value' means the column or the connection cannot hold the bytes you sent. How to read the hex in the message, convert tables to utf8mb4 safely, and handle the 'Unknown collation utf8mb4_0900_ai_ci' error when moving between MySQL and MariaDB.

Dev & Infrastructure3 min read

My Scheduled Job Ran Twice (or Not at All) When the Clocks Changed: Fixing Daylight Saving Bugs

When clocks fall back, 01:30 happens twice. When they spring forward, 02:30 never happens. Jobs, billing runs, and reports scheduled in local time can double-run or vanish. Real examples with Python, plus the schedule and coding rules that prevent it.

Dev & Infrastructure3 min read

TLS Certificates Are Getting Shorter: 200 Days Now, 100 in 2027, 47 in 2029 (What to Automate Before It Hurts)

Since March 15, 2026 public TLS certificates can last at most 200 days. The limit drops to 100 days in March 2027 and 47 days in 2029. A concrete guide for small sites: how to check what you have, what cannot be automated, and the options for NAS boxes, routers, and appliances.