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

The week

Most executives have never thought about digital certificates, and that is how it should be. They work in the background every time someone visits a secure website. But in mid-June 2026, a change to how those certificates are issued began to reach into places most organizations had never mapped: the private connections between banks and payment processors, insurers and clearinghouses, agencies and their data partners.

A quick primer. A digital certificate is an electronic credential, a little like a passport, that lets one computer prove its identity to another. Certificates are issued by certificate authorities, trusted organizations that vouch for who you are, much as a passport office does. The whole system of issuers, rules and trust is called a public key infrastructure, or PKI. Browser makers such as Google decide which certificate authorities their browsers will trust, and they set rules those authorities must follow to stay on the list.

June 15, 2026 was the first hard date in Google’s plan to separate two jobs that public certificates had long done together: proving a server’s identity, and proving a client’s identity. Under version 1.8 of the Chrome Root Program Policy, updated in February 2026, any new subordinate certificate authority, an issuing office that operates under a Chrome-trusted root, disclosed from that day must assert server authentication only.

The rule for end-entity certificates, the ones actually installed on servers and systems, came later. Those issued on or after March 15, 2027 may carry only the server authentication extended key usage, the label inside a certificate that says what it may be used for. Earlier versions of the policy had pointed to June 2026 for both, so the deadline for these everyday certificates had moved.

Certificate authorities, however, did not all wait for Google’s later date. 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 client authentication by default in October 2025 and plans to stop entirely on March 1, 2027.

So in the week of June 15, the headline deadline was nine months away, while the practical deadlines, set by the companies that actually issue certificates, were already arriving.

For most websites none of this matters, because a browser only checks that a certificate proves the server’s identity. When you visit your bank’s website, your browser asks, in effect, “Are you really the bank?” The certificate answers yes. Nobody asks the browser to prove who it is.

The change bites where organizations had 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. The machinery comes first.

Certificates, mutual TLS and the label inside each one

TLS, short for Transport Layer Security, is the technology behind the padlock in your browser. It does two things: it scrambles the data traveling between two computers so eavesdroppers cannot read it, and it lets at least one side prove its identity using a certificate.

In ordinary web browsing, only the server proves itself. Mutual TLS, often written mTLS, is the version where both sides show credentials. Organizations use mutual TLS for machine-to-machine connections where they want certainty about who is on the other end, such as a bank sending payment files to a processor.

An API, or application programming interface, is a doorway that lets one organization’s software ask another organization’s software for information or to perform an action, automatically and without a person in between. Many APIs between businesses are protected with mutual TLS.

Every certificate carries a small field called the extended key usage, which lists the jobs it is allowed to do. “Server authentication” means it can prove a server’s identity. “Client authentication” means it can prove a client’s identity. For years, many public certificates carried both labels, so a company could buy one certificate and use it both for its website and for its outgoing connections to partners. It was convenient, and for a long time nobody minded.

Browsers, however, only care about the server job. Google’s view, reflected in its root program policy, is that public certificates should be dedicated to the web, and that other uses should run on separate systems with their own rules. Removing the client label is how that separation is being enforced.

How certificates actually live inside an organization

The change is hard to manage because of how certificates are handled day to day in a typical bank, insurer, hospital system or agency.

Certificates are not bought once and forgotten. Each one has an expiry date, after which it stops working. Someone, or some automated tool, has to request a replacement from the certificate authority, receive it and install it in the right place before the old one runs out. In a large organization there can be thousands of certificates spread across websites, internal systems, file transfer servers, cloud services and specialist equipment.

Responsibility is usually scattered. The web team manages the certificates on public websites. The integration team looks after the connections to partners. An infrastructure group handles network devices. A vendor may manage certificates on a platform it hosts for you. Each group renews its own certificates on its own schedule, often from more than one certificate authority, because different teams bought from different suppliers over the years.

Renewal is often treated as routine housekeeping. The request goes out, a new certificate comes back with the same name and installation takes a few minutes. The person doing the renewal rarely checks whether the new certificate carries exactly the same permissions as the old one. Until recently, there was no reason to. This change slips through exactly that gap: a renewal that looks identical on the surface but lacks the client label.

Finally, the people who know which certificate is used for which connection are often not the people who renew it. The engineer who set up a partner link five years ago may have moved on. The knowledge lives in configuration files and in people’s memories, not in a central record. When leaders ask “are we affected?”, the honest first answer is often “we need to look.”

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, the opening exchange in which the two computers check each other’s credentials. Nothing changes until the renewal date, and then the job fails, often overnight.

Suppose a regional bank runs an automated job at 2 a.m. every night that sends the day’s payment instructions to its card processor using a certificate the bank renews routinely. The renewal goes through in April, the new certificate is installed and everything looks normal on the bank’s dashboards. That night, the processor’s server looks for the client label, does not find it and refuses the connection. By morning, payments are stuck, customers are calling and the operations team is trying to work out why a routine renewal broke something nobody had touched.

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. The CA/Browser Forum is the industry body where certificate authorities and browser makers agree the baseline rules for public certificates. A certificate renewed in the spring will be renewed again late in 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 these links by searching configuration files and keystores, the secure files where systems store their certificates, for certificate references, by reviewing partner onboarding records, and by 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, the front door that screens incoming requests from partners, or your 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: a gate that waves through credentials that are not fit for purpose is not much of a gate.

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.

This is a customer and partner relationship issue as much as a technology one. If a partner’s connection fails because of a change you could have told them about, they will experience it as your outage, regardless of whose certificate expired.

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. An appliance is a piece of dedicated equipment, such as a network device or a specialist server, that runs its manufacturer’s software rather than software the organization controls. Some only accept certificates loaded by hand, and some cannot be configured to trust a private root without a firmware update, meaning an update to the built-in software supplied by the manufacturer.

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.

A public certificate works like a passport: recognized everywhere but governed by rules you do not set. A private certificate is like a company ID badge. Only the buildings that agree to recognize it will accept it, but you decide how it is issued, how long it lasts and how quickly it can be cancelled. For machine-to-machine connections between known partners, the badge is often the better tool.

The trade-offs are real. A private authority has to be operated, protected and audited. If its master keys were stolen, an attacker could issue convincing credentials, so it needs serious security. 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.

Consider how this might play out at a health insurer with a few dozen provider and clearinghouse connections. Rather than wait for each certificate to fail, it sets up a private certificate authority through a managed service, writes to each partner with a timetable and a test environment, and migrates connections in batches over several months. Each partner gets a new client credential from the insurer’s own authority before the old public certificate is due for renewal. Some partners move quickly; a few need follow-up calls and a longer window. But every connection moves on a date someone chose, with people watching, instead of on whatever night a renewal happened to land. The project is unglamorous. Done early, it is a scheduled piece of work rather than an incident.

What a failed handshake costs the business

It is easy to file certificates under “IT plumbing.” The consequences are not plumbing.

• Revenue and operations. When a payment file, a claims submission or a regulatory report fails to send, the business process behind it stops. In financial services and healthcare, that can mean delayed payments, missed deadlines and customer complaints within hours.
• Regulatory exposure. Supervisors expect firms to manage technology dependencies and third-party connections. An outage caused by a published, long-announced change is hard to explain as bad luck.
• Partner trust. Many of these connections exist because a partner agreed to rely on you. Breaking them repeatedly, one renewal at a time, damages relationships.
• Hidden cost of surprise. Fixing a certificate problem calmly over several weeks is cheap. Fixing it at 3 a.m. while payments are queued is expensive, stressful and error-prone.

Habits of the organizations that get ahead of it

Organizations that handle this well share a few habits. They keep an inventory that records where each certificate is installed, what it is used for and which connections depend on it. They know, for every certificate authority they buy from, that authority’s own cutoff dates. They have told partners, in writing, what kind of client credentials they will accept going forward. And they treat renewal as a planned event with an owner, not an automated background task nobody watches.

The ways it goes wrong are predictable.

• Trusting the headline date. Teams read “March 2027” in a browser policy and assume they have until then, without checking their issuer’s earlier schedule.
• Relying on the certificate inventory alone. An inventory shows where a certificate lives, not which jobs use it as a client credential.
• Forgetting the inbound side. Organizations fix their own certificates but do not prepare for partners whose renewals will change what arrives at the gateway.
• Loose acceptance rules. Gateways that accept any publicly trusted certificate, whatever its stated purpose, weaken security.
• Solving it one renewal at a time. Patching each failure as it happens, rather than choosing a long-term trust model, guarantees a stream of small incidents.

Where the renewal risk sits now

• Which of our connections to partners, processors, payers or agencies use certificates to prove our identity, and who owns each one?
• For each certificate authority we buy from, when does it stop issuing certificates that can be used as client credentials?
• Have we told our inbound partners what kind of client certificates we will accept after their next renewal?
• Do our gateways check what a certificate is allowed to be used for, or only that it is publicly trusted?
• With certificates now renewing roughly twice a year, who is watching each renewal, and how would we know if one broke something?

With hindsight

The dates 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 spread changes the nature of the risk. A single, well-publicized deadline tends to concentrate attention: everyone knows the date, teams prepare and someone is watching on the day. A rolling series of renewals produces the opposite effect. Each failure arrives on its own schedule, often at night, in a different system, owned by a different team. None of them looks like a big event, so none of them gets big-event preparation. The total disruption can still be significant.

The general pattern still applies, well beyond this particular change. Public certificates follow browser policy, which keeps changing, and shorter lifetimes mean more renewals. Each renewal is a moment when a new rule can take effect inside a system that has worked for years.

An inventory of where each certificate is used, as well as where it is installed, is what turns those renewals into planned events. The technology team almost certainly understands certificates. What matters is whether anyone has connected each certificate to the business process it supports, and whether that person will know before the renewal, rather than after, that something is about to break.