TLS Certificate Management: What’s Changing & Why

TLS Certificate Management Is at an Inflection Point

TLS certificate management has never been simple, but it’s getting measurably harder. Browser root programs are tightening their requirements. Validity periods are shrinking toward timelines that make manual renewal impractical. And policy changes are forcing organizations to separate certificate types that have historically lived in the same environment.

Each of these changes has a direct operational consequence. Shorter validity periods put pressure on renewal workflows. The separation of server and client authentication attributes forces architectural decisions that previously weren't necessary. And validity periods for OV and EV certificates have been tightened to 200 days.

For security teams and the business leaders who support them, understanding how these pieces connect is the starting point for a more defensible certificate strategy.

Google’s EKU Change & What It Means for Mutual TLS

One of the most consequential near-term changes in the publicly trusted certificate space is coming from Google. Through its participation in the CA/Browser Forum, the industry body that sets baseline requirements for certificate authorities, Google has announced it will no longer trust digital certificates that carry both server authentication and client authentication attributes in the Extended Key Usage (EKU) field.

To understand why this matters, it helps to know what those two attributes do. A server authentication attribute tells a browser or client that a server is who it claims to be. A client authentication attribute does the reverse, allowing a server to verify the identity of a connecting client. Certificates that carry both have historically been used to enable mutual TLS (mTLS), a handshake in which both sides of a connection authenticate each other.

Google is requiring those two functions to be separated. Server certificates will continue to be publicly trusted and remain globally valid wherever Chrome is used. Client authentication certificates, however, will need to go a different route.

Here’s a practical example: a financial services firm using publicly trusted certificates to authenticate internal services over mTLS would need to split those certificates before Google's deadline, replacing the combined-use certificates with separate server and client authentication credentials.

What Happens to Client Auth Certificates

With public trust for client authentication no longer a given, organizations have two primary paths forward.

The first is private PKI. For many internal machine-to-machine environments, public trust was never strictly necessary, just convenient. If an organization’s client auth certificates are only validated within its own infrastructure, establishing a private certificate authority to issue them is a viable option. It does require internal management overhead, but that’s where PKI-as-a-service can help.

Rather than building and maintaining the infrastructure entirely in-house, organizations can offload certificate lifecycle management to a provider while retaining control over their private trust environment. For organizations with mature PKI teams already in place, self-managed private PKI remains a reasonable fit.

The second path is where the identity validation question becomes interesting. There are scenarios where public trust in a client auth certificate isn’t just a convenience. It’s the point. Consider an organization that needs to give external parties access to a portal or service and wants those parties’ identities validated before issuing credentials. Outsourcing that identity verification to a trusted certificate authority makes the process more defensible and reduces the burden on the relying party.

For business leaders evaluating third-party access controls or supply chain authentication, a publicly trusted client auth certificate means the relying party doesn’t have to perform that identity check independently.

Domain Validation Is Getting Harder to Manage

Domain validation is a requirement for all publicly trusted TLS certificates: DV, OV and EV. As reauthorization windows shrink, operational pressure is felt across the board.

The CA/Browser Forum has been systematically reducing the maximum validity period for publicly trusted TLS certificates. That period is currently only 200 days, but it will be 47 days starting March 15, 2029. Similarly, the domain verification data reusage period will soon shrink from 200 days to 10 days beginning on March 15, 2029. For an organization managing a handful of domains, that’s an inconvenience. For organizations managing certificates across dozens or hundreds of domains, it creates a workflow problem that puts real pressure on TLS certificate management processes.

One development worth noting is the introduction of persistent DCV (domain control validation) text values. Traditionally, whenever a domain needed to be revalidated, a new DCV value had to be retrieved and added to the domain’s DNS record. With persistent DCV values, organizations set the validation record once, and the CA can use it automatically for verification, removing a manual step from the certificate lifecycle and making automation more reliable.

For smaller organizations, this may sound like a minor quality-of-life improvement. At scale, it’s a meaningful step toward making automated certificate management workable.

Automation Is No Longer Optional

The thread running through all of these changes is automation, and its implications for TLS certificate management are significant. Shorter validity periods, more frequent revalidations and increasingly complex certificate environments mean that organizations relying on manual processes are building in risk.

The Automated Certificate Management Environment (ACME) has become the default mechanism for issuing and renewing TLS certificates, particularly as validity periods continue to shrink. For organizations already operating ACME-based workflows, shorter lifespans are an operational adjustment. For those that are not, the need to automate is no longer a future concern — it is a near-term requirement.

What’s changing is not whether automation is used, but how it is applied. As certificate environments become more segmented — separating server and client authentication, mixing DV with OV and EV, and supporting both internal and external trust models — automation has to respect those distinctions rather than flatten them.

IdenTrust supports ACME as a foundational capability, enabling organizations to automate issuance and renewal without disrupting existing providers or workflows. More importantly, that automation is designed to operate in context: aligning certificate type, validation level, and trust model with the role each certificate plays. As TLS certificate management shifts from a renewal problem to an identity governance challenge, automation must reinforce trust decisions — not bypass them.

Automation requirements vary by organization size, but the need itself doesn't. Enterprise teams managing complex multi-environment deployments need automation that can handle certificate separation, knowing which endpoints require server certificates, which require client auth certificates and how each category gets managed going forward. Smaller organizations need lightweight automation that doesn’t require standing up significant infrastructure.

The pressure toward automation is not coming from any single browser or policy body. It’s the cumulative effect of an industry that has decided provable identity and frequent revalidation are worth the operational investment. For organizations looking to get ahead of it, a few practical starting points:

• Audit current mTLS environments to identify certificates that carry both server and client authentication attributes and will need to be separated ahead of Google’s policy change
• Evaluate whether client auth use cases require public trust or whether private PKI is a more appropriate fit for internal environments
• Assess TLS certificate volume against current renewal workflows to understand where automation gaps exist before validity periods shrink further

Identity Is the Constant

Taken individually, each of these changes has a workaround. Taken together, they point toward something more significant: the industry is raising the bar on what it means to establish trust in a digital environment. Shorter validity periods mean identity can’t just be verified once and forgotten. Separated EKU attributes mean the architecture of trust has to be more deliberate.

For organizations that need a CA with the depth to handle that rigor, IdenTrust has been doing this work for decades. A good starting point is a certificate inventory. Knowing what you have, where it lives and which certificates carry combined EKU attributes will clarify the scope of what needs to change. The rules are changing, but the underlying principle isn't: trust has to be earned, verified and maintained. The organizations that treat certificate management as a strategic function rather than an operational afterthought will be better positioned for what comes next.

If the changes covered here have you rethinking your certificate strategy, IdenTrust’s TLS/SSL website security page is a good place to start >>