The question arrives in almost every conversation now. Public certificate lifetimes are on a schedule that ends at 47 days, and somebody has read a headline and wants to know whether the hierarchy we just built has to start reissuing everything monthly. It does not. But the reason it does not is worth understanding properly, because the test people apply to work it out is the wrong one.
Two systems share a technology and almost nothing else. One of them is the public web certificate ecosystem, governed by a forum of certificate authorities and browser vendors, whose rules exist because a browser has to make a trust decision about a server it has never seen on behalf of a user who cannot evaluate it. The other is a private certificate authority, governed by you, whose rules exist because you decided them. They use the same certificate format and the same validation logic. They are not the same system and they are not converging.
What is actually happening, and when
The maximum lifetime of a publicly trusted server certificate is being reduced in steps rather than in one move, and the first step has already passed. Certificates issued before the middle of March 2026 could run to 398 days. From that point the ceiling is 200 days, and some authorities issue a day short of it to keep a margin. From March 2027 it is 100 days. From March 2029 it is 47.
The change that gets less attention matters more operationally. The period for which a certificate authority may reuse the evidence that you control a domain drops to ten days at the same point in 2029. That means renewal cannot simply be a matter of re-requesting a certificate on a schedule. The validation itself has to be automated, which is a different and larger piece of work than automating issuance, and it is the part that catches organisations who assumed a script around their existing process would carry them through.
None of it applies to a certificate your own authority signed. Not the 47 days, not the 200, not the validation reuse window.
These are requirements on certificate authorities that browsers and operating systems choose to trust by default. Your root is trusted because you put it there. Nobody is auditing it, nobody is going to distrust it, and the rules that keep the public ecosystem honest have no mechanism to reach it and no reason to.
The test is the issuer, not the location
Here is where most people get it wrong, and it is an understandable mistake. The instinct is to sort certificates by where the server sits. Internal servers are unaffected, internet-facing servers are affected. That rule gives the right answer most of the time and the wrong answer in exactly the cases that hurt.
The deciding question is who signed it. A certificate from a publicly trusted authority is governed by the public rules no matter where it lives, and there are more of those inside corporate networks than anyone expects: the internal application somebody bought a certificate for because it was easier than filing a request, the management interface on an appliance that shipped with a public certificate, the internal API a team stood up in a hurry. Every one of those is on the shortening schedule and none of them is on anybody’s list.
It runs the other way too. A service reachable from the internet and used only by devices you manage can perfectly well carry a certificate from your own authority, because the only clients that need to trust it already do.
| What it is | Who should sign it | On the shortening schedule |
|---|---|---|
| Public website or public API | Publicly trusted authority | Yes |
| Browser-facing VPN or remote access portal | Publicly trusted authority | Yes |
| Anything an unmanaged visitor opens | Publicly trusted authority | Yes |
| Internal site, internal API, management interface | Your issuing authority | No |
| Secure LDAP, domain controllers | Your issuing authority | No |
| Machine and user authentication, wifi, VPN client certificates | Your issuing authority or the cloud service | No |
| Certificates issued to managed devices over SCEP | The cloud service | No |
| An internal service somebody bought a public certificate for | Publicly trusted authority, whether you meant it or not | Yes |
One appliance, two certificates, two worlds
The example that makes this concrete, and the one I reach for when somebody is not convinced the distinction is real, is a remote access appliance.
It presents a portal to a browser. That browser belongs to somebody on a home machine or a hotel network, it has never heard of your organisation, and it will refuse the connection unless the certificate comes from an authority it already trusts. So the portal carries a publicly trusted certificate, and that certificate is on the shortening schedule, and by 2029 it needs replacing roughly monthly with automated domain validation behind it.
The same appliance also authenticates users and devices by certificate. Those certificates come from your authority, are validated against a root the appliance was configured with, and are entirely outside the public rules. They can run for a year, as this series sets them to, and the CA/Browser Forum has no opinion about them whatsoever.
One device, two certificates, two completely different lifecycles, and an administrator who does not hold the distinction will either shorten the wrong ones or fail to shorten the right ones. Both mistakes are expensive and only one of them announces itself.
What not to do about it
The reflex, when a security headline lands, is to apply it everywhere on the grounds that shorter must be safer. Do not shorten your templates to 47 days. You would multiply renewal traffic across every machine, user and domain controller in the estate, take on the operational risk that comes with any high-frequency automated process, and satisfy no requirement that exists, because no browser is ever going to look at these certificates.
The one-year end-entity lifetime this series settles on is a judgement about blast radius and operational load, and it remains the right judgement. If you want to shorten something, shorten it because you have decided a compromised key should have a shorter life, and be honest that the reason is yours rather than borrowed.
Equally, do not use your private authority for anything an unmanaged client has to trust. It will not work, the failure is immediate and total, and the instinct to fix it by asking users to install your root certificate is how organisations end up training people to click through certificate warnings. [P 5.1] Build Sheet: The Template Set makes the same boundary explicit at the two web server templates, which is where you would otherwise reach for the wrong one.
The conclusion nobody selling software will offer you
There is a second-order effect in all this that gets very little attention, and it points the opposite way to the general mood.
As public certificates move to a lifetime measured in weeks with automated domain validation attached, the cost of using one goes up. Not the price, the operational cost: the automation to build, the failure modes to monitor, the appliances that cannot speak the protocols, the renewal that now has to succeed ten or twelve times a year instead of once, unattended, every time. For a service that genuinely faces the public, that cost is unavoidable and worth paying.
For a service that does not, it is a cost you were never obliged to take on. An internal application, an appliance management interface, an internal API, a directory service: every one of those can be served by an authority you control, on a lifetime you chose, with no external dependency and no renewal treadmill. The shortening schedule makes that a better deal every year it advances.
So the boundary this article is arguing for is not a compliance exercise. It is a division of labour. Public certificates for the things strangers must trust, automated end to end because there is no other way to survive them. Your own authority for everything else, which is most of it, on terms you set. Keep the two apart in your head and the 47-day headline stops being a problem you have and becomes a problem you scoped.
On-Prem PKI
‹ Previous: [P 9] A Second Issuing CA: When It Is Availability, When It Is a Boundary, and When It Is Neither
Next: [P 11] Retiring a Certificate Authority Without Taking the Estate With It ›
