Public TLS Certificates Lose clientAuth (2026–2027): Which Mail Servers Break

Short answer: Public CAs are removing TLS Client Authentication (clientAuth) from server certificates. Let's Encrypt's last dual-purpose certificates expired around 6 Oct 2026, Sectigo and DigiCert stop on 10 Feb and 1 Mar 2027, and Chrome requires serverAuth-only for certificates issued from 15 Mar 2027. Mail breaks only where a receiver verifies your public certificate as a client certificate, such as Postfix with permit_tls_all_clientcerts. Exchange Online connectors don't need clientAuth.

Who	Chrome Root Program, Let's Encrypt and the public CAs
Status	confirmed
Dates	2025-10-01: DigiCert stops adding clientAuth by default (still available on request) 2025-10-14: Sectigo stops adding clientAuth by default 2026-02-11: Let's Encrypt's default (classic) profile drops clientAuth 2026-04-13: Google Trust Services stops issuing clientAuth (week of 13 Apr 2026) 2026-07-08: Let's Encrypt ends its temporary tlsclient profile; its last dual-purpose certificates (90 days) expired around 6 Oct 2026 2026-09-13: GlobalSign issues public TLS only from its TLS-only roots 2027-02-10: Sectigo stops clientAuth completely, "no exceptions" 2027-03-01: DigiCert stops clientAuth completely (moved from 1 May 2026) 2027-03-15: Chrome Root Program: certificates issued from this date may only assert serverAuth 2027-09: The last dual-purpose certificates from Sectigo and DigiCert expire (up to 200 days after their last issue date; our estimate)

Who is affected

Only setups where a receiving mail server or gateway verifies the sending server's public certificate as a TLS client certificate: OpenSSL-based Postfix with permit_tls_all_clientcerts or smtpd_tls_req_ccert, Exim with tls_verify_hosts, and partner or relay gateways that require mutual TLS with a publicly trusted certificate. Postfix fingerprint matching (permit_tls_clientcerts, check_ccert_access) keeps working, and so do Exchange Online certificate-based connectors: Microsoft says certificates used to relay to Exchange Online don't need the clientAuth EKU. Most server-to-server mail uses no client certificate at all.

What you will see

OpenSSL 3.0.8 and later: unsuitable certificate purpose (X509_V_ERR_INVALID_PURPOSE, error 26); OpenSSL 1.1.1 to 3.0.7 print unsupported certificate purpose
Postfix (receiver): certificate verification failed for <host>[<ip>]: not designated for use as a client certificate (logged with smtpd_tls_req_ccert or the untrusted log level; at the default level only "Untrusted TLS connection established from ..." appears)
Postfix with smtpd_tls_req_ccert = yes: the sender gets 421 4.7.1 <host> Error: Client certificate not trusted
Exim (OpenSSL build): SSL verify error: depth=0 error=unsuitable certificate purpose cert=<DN>, followed by TLS error on connection from ... (SSL_accept)
A partner or relay that accepted your mail by certificate stops relaying right after your certificate was renewed.

Check your setup today

See what your server presents: our certificate check reads the certificate on port 587, 465, 993 or 443 and lists its Extended Key Usage and expiry. Or run openssl s_client -starttls smtp -connect mail.example.com:587 </dev/null 2>/dev/null | openssl x509 -noout -ext extendedKeyUsage -enddate.
If the list shows TLS Web Client Authentication, the date that matters is its expiry: the renewal will come without it. On 26 Oct 2026 the certificates of outlook.office365.com (DigiCert), smtp.gmail.com (Google Trust Services) and mailpassed.com (Let's Encrypt) were already serverAuth only.
Find out whether anyone verifies your certificate as a client certificate: on Postfix receivers look for permit_tls_all_clientcerts or smtpd_tls_req_ccert = yes, on Exim for tls_verify_hosts, and ask partners or relays that "authenticate you by certificate".

How to fix it

Use a private CA for client certificates and have the receiver trust that CA only. DigiCert, Sectigo, Google Trust Services and SSL.com all point to private or dedicated client-authentication certificates.
Postfix receivers: match senders by fingerprint with check_ccert_access or permit_tls_clientcerts instead of trusting any public certificate with permit_tls_all_clientcerts. Fingerprint matching doesn't need a trusted chain, so the missing EKU doesn't matter; update the fingerprint at every renewal.
Exim receivers: switch tls_verify_hosts to tls_try_verify_hosts and check the result in an ACL, or trust a private CA with tls_verify_certificates. Exim's own documentation suggests a private CA for client certificates.
Exchange Online: nothing to change. Certificate-based connectors don't need clientAuth, and Microsoft recommends them over IP-based connectors for on-premises servers (MC1226222).
Stop-gap only: Sectigo (until 10 Feb 2027) and DigiCert (until 1 Mar 2027) still add clientAuth on request, which buys at most 200 more days.

Check your domain now

After the fix, send a test email to see SPF, DKIM and DMARC pass on a real message, then keep an eye on it: free DMARC monitoring shows every service that sends mail as your domain and which ones fail, in plain English.

Rather not touch DNS? I set up SPF, DKIM and DMARC without breaking your other senders, with a before/after report.

Get it fixed on Fiverr

Prefer to do it yourself? Get the step-by-step Fix Kit ($15) – 28-page guide, checklist, 20+ providers.

Sources

Did this fix it?