The client-certificate deadline that moved, and the certificate authorities that didn’t wait

The week

June 15, 2026 was the first hard date in Google’s plan to separate server and client authentication in the public web PKI. Under version 1.8 of the Chrome Root Program Policy, updated in February 2026, any new subordinate certificate authority disclosed from that day under a Chrome-trusted root must assert server authentication only. The rule for end-entity certificates came later: those issued on or after March 15, 2027 may carry only the server authentication extended key usage. Earlier versions had pointed to June 2026 for both, so the leaf deadline had moved. Certificate authorities did not all wait. Let’s Encrypt dropped client authentication from its default profile in February 2026, closed a fallback profile to new users on May 13 and ended it on July 8. DigiCert stopped including it by default in October 2025 and plans to stop entirely on March 1, 2027.

For most websites none of this matters, because a browser only checks that a certificate proves the server’s identity. The change bites where organizations had quietly used the same public certificate for a second job: proving their own identity as a client in mutual TLS. That pattern is common in bank-to-processor links, payer and clearinghouse connections, government data exchanges and vendor APIs. The browser policy set the outer limit. The effective date for each connection was set by the certificate authority that issues the certificate at its next renewal, and that date was often much earlier. We separate the problem into three exposures, which differ by who must act, and one decision that resolves them. The exposures are outbound connections, inbound connections and internal services. The decision is whether to move client authentication to a private PKI.

Outbound: where you present a public certificate as a client

The first exposure is your own systems authenticating to someone else. Examples include a file transfer job that pushes payment files to a processor, an integration engine that calls a payer API, and a reporting system that submits to a state agency. Any of them may present a certificate bought from a public authority. If the next renewal comes back without client authentication, the partner’s server rejects the handshake. Nothing changes until the renewal date, and then the job fails, often overnight.

Renewals are also arriving faster. Since March 15, 2026, new public TLS certificates have been limited to 200 days of validity under CA/Browser Forum rules. A certificate renewed in the spring will be renewed again around the turn of the year. That shortens the window between discovering a dependency and having it break, and it means the issuing authority’s schedule, not the browser’s, decides which renewal is the first one without client authentication.

Finding these links requires looking at client configurations, not certificate inventories alone. An inventory may show a certificate for a host name. It rarely shows that a scheduled job uses that certificate as a client credential. Teams usually find them by searching configuration files and keystores for certificate references, reviewing partner onboarding records, and asking application owners which integrations use certificate-based authentication. Each link found needs an owner, a renewal date and a replacement plan agreed with the partner.

Inbound: where you accept partners’ public certificates

The second exposure runs the other way. Your API gateway or file transfer server may authenticate partners by checking that their client certificate chains to a public root and matches an expected name. When those partners renew, their certificates may no longer carry client authentication. Some servers will reject them. Others may be configured loosely enough to accept them anyway, which is a separate problem.

The work here is partly technical and partly contractual. Gateways need a list of which partner identities are accepted on what basis. Partners need advance notice of the trust model you will accept next, such as certificates from a named private authority you operate or from a dedicated client-certificate service. Onboarding agreements and interface specifications should say so. An organization with hundreds of partners cannot coordinate this in the month before a renewal wave.

Internal: where devices and services reused public certificates

The third exposure is inside the network. Some internal services, appliances and devices were set up years ago with public certificates because they were easy to obtain and trusted everywhere. Where those services authenticate to each other with the same certificates, the effect is the same as the outbound case, but the partner is another team. Appliances add a complication. Some only accept certificates loaded by hand, and some cannot be configured to trust a private root without a firmware update.

These cases are often the hardest to find, because nobody outside the owning team knows the dependency exists. Network traffic analysis that flags mutual TLS handshakes, combined with configuration review, is the most reliable way to surface them. Each one found is also a candidate for moving off public certificates altogether.

The architecture choice: a private client PKI

Each of the three exposures has the same underlying fix. Public certificate authorities are run for the web, under browser rules that will keep changing. Client authentication between organizations and between internal services needs a trust model the parties control. That usually means a private certificate authority, run in-house or as a managed service, with its own issuance rules, lifetimes and revocation, and with automated enrollment wherever the platforms support it.

The trade-offs are real. A private authority has to be operated, protected and audited. Partners must agree to trust it, which takes negotiation. Some sectors already have shared trust frameworks for this purpose, and using them is usually cheaper than building one per relationship. The cost of the move is lower now, while existing certificates are still valid, than it will be when each renewal forces a decision under pressure.

With hindsight

From October 2026, the dates have held. Let’s Encrypt ended its fallback profile on July 8 as announced, so no new Let’s Encrypt certificate carries client authentication. DigiCert still offers the dual-purpose option on request until March 1, 2027, and Chrome’s leaf deadline remains March 15, 2027. Because existing certificates stay valid until expiry, the last public dual-purpose certificates will drop out of service during 2027. A certificate issued just before DigiCert’s cutoff can run for up to 200 days, into the autumn. That spreads the exposure across many separate renewal dates rather than one cutover, which makes failures harder to anticipate from a calendar. The general pattern still applies. Public certificates follow browser policy, which keeps changing, and shorter lifetimes mean more renewals. An inventory of where each certificate is used, as well as where it is installed, is what turns those renewals into planned events.