Two changes to public TLS certificates came into force this year, and together they change how certificate management needs to be done. If your team still renews certificates once a year and installs them by hand, that process has less than six months left before it starts causing real problems, because the maximum lifetime of a public certificate drops again to 100 days in March 2027.

At Digitalis.io we implement TLS across a large number of client estates, most of which are Cassandra, Kafka and Elasticsearch clusters running in production. We automate certificate installation and rotation wherever we can, because it removes the risk that comes with updating SSL/TLS certificates by hand.

Certificate lifetimes are getting shorter

In April 2025 the CA/Browser Forum passed Ballot SC-081v3, which sets a common schedule of reductions in certificate validity that every publicly trusted certificate authority has to follow over the next few years. No individual CA chose to do this and the rules apply to all of them equally, which is why GoDaddy, DigiCert, Sectigo and the other commercial authorities changed their offerings at around the same time, and why switching provider to get a longer certificate is no longer an option.

Any certificate you have bought from a public CA since March will be valid for roughly 200 days. Most authorities issue a day or two short of the maximum to leave themselves some margin, which is why DigiCert chose 199 days when it made the switch in February.

Domain validation reuse will have the bigger impact

The right hand column of that table gets much less attention than the certificate lifetimes, even though it will have a bigger effect on how you work. The left hand column sets how long a certificate stays valid once it has been issued, while the right hand column sets how long a CA can rely on an earlier proof that you control a domain before it has to ask for that proof again. These are two separate clocks and both are being reduced on the same schedule.

Before a CA issues a certificate for a name like cluster.example.com, it has to confirm that you control that name, which is the step where you publish a token in DNS, serve a file over HTTP or respond to an email challenge. This is known as domain control validation, and once it succeeds the CA is allowed to store the result and reuse it for later certificates covering the same name. Under the old rules that stored result stayed valid for 398 days, so a typical workflow with a commercial CA meant validating your domains about once a year, and any reissue or rekey in between was little more than filling in a form because the validation on file was still current.

The ballot shortens how long a stored validation can be reused, from 398 days to 200 days now, then to 100 days in March 2027 and finally to 10 days in March 2029. At ten days a stored validation is of very little practical use, because almost every issuance will need a fresh proof at the time the certificate is requested.

This is more significant than the shorter lifetime because the two changes affect different parts of your process. A shorter lifetime means installing certificates more often, which is tedious but is something you already have a runbook for. A shorter reuse period means the validation step also has to run more often, and that step usually depends on systems outside the cluster and often outside your team, most commonly DNS. If another team manages your DNS, or it sits in a registrar console that someone logs into manually, nobody can realistically keep up with a validation that has to be repeated every ten days. You will need either API access to the zone or a delegated CNAME that points the challenge records at a zone your automation controls.

Teams already using ACME have been working under this kind of rule for years without really noticing, because Let's Encrypt caches an authorisation for up to 30 days and the client revalidates automatically whenever it needs to. The organisations that will feel the ten day limit are the ones still buying certificates through a web portal, where the annual validation was a real convenience rather than a detail their tooling already handled.

One point of clarification on the table, since the ballot actually defines two reuse periods. The column shown above applies to the domain names in the SAN, which covers nearly everything you are likely to issue. There is a separate reuse period for the organisation identity information used in OV and EV certificates, and that one drops from 825 days to 398 rather than to 10, so if you hold OV certificates for client facing services the identity paperwork side is changing far less dramatically.

Public certificates can no longer be used for client authentication

The second change has had less coverage but is more likely to break something. The Chrome Root Program now requires every public certificate hierarchy to be dedicated to server authentication. Any intermediate CA disclosed since 15 June 2026 has to be limited to server authentication, and from 15 March 2027 no newly issued public certificate can include the TLS Client Authentication extended key usage. Certificate authorities are moving ahead of that deadline. Let's Encrypt shut down its tlsclient profile on 8 July 2026, and the commercial CAs are each removing the option on their own timelines.

If you rely on publicly trusted certificates for mutual TLS anywhere, such as client certificates presented to a Kafka cluster, application identities connecting to Cassandra, or service to service authentication within Kubernetes, the certificates you already hold will keep working until they expire, but once your CA has made the change you will not be able to renew them with client authentication included. The way forward is to issue client identities from a private certificate authority and keep public certificates for the server side, where browsers and external clients need to trust them.

We think this separation makes sense regardless of the deadline. A public CA only ever confirmed that you controlled a particular domain name, and that was never the same as confirming that a given client was authorised to connect to your cluster.

Certificate rotation is harder on a data platform than on a web server

Rotating a certificate on a web server is a small and well understood task, but doing the same across a distributed data platform is a much larger job. The certificate usually lives in a Java keystore rather than as a file on disk, every node has a matching truststore that has to stay consistent with it, and when node to node encryption is enabled the whole cluster has to move together, so a mistake can take the cluster down rather than a single endpoint.

Recent versions of Cassandra, Kafka and Elasticsearch can reload certificate material without a full restart, which helps a great deal where it is available. Plenty of production estates are running older versions, though, or depend on keystores that were built by hand years ago and that nobody is keen to touch. When certificates expired once a year it was possible to treat all of this as an annual chore, but with expiry now every 200 days, and every 100 days from next March, a manual process becomes a recurring outage risk that will eventually catch someone out at three in the morning.

Start with a certificate audit, then automate rotation

We build and run certificate rotation for clients as part of our managed service and consultancy work. We usually start with an audit of every certificate across the estate and when each one expires, and that audit almost always turns up more than people expect. From there the work normally involves setting up or tidying an internal CA for mTLS and node to node traffic, automating issuance and renewal with ACME or cert-manager, integrating rotation with the cluster so that keystores and truststores are updated without an outage, and adding expiry monitoring so that nobody first hears about an expired certificate in an incident channel.