You may have noticed two things being promoted in public recently regarding X.509 PKI certificates. One is an announcement from Digicert that its TLS certificates will now have a 47-day lifetime. The other is Let’s Encrypt’s release of even shorter-lived six-day certificates, which is a significant step down even from 47.
What’s going on?
The answer is that people have reassessed the risk issues associated with certificate lifetimes.
In the past, it was common to obtain certificates through a heavyweight process involving explicit paperwork and external trust information (for example, from a company registry or public notary). Certificates often cost hundreds of dollars and last a year (a typical billing cycle), or even longer. You could pay in advance and get three years, or five. At that time, installing certificates was complicated and manual. Naturally, the goal was to do it as infrequently as possible.
Today, the dominant method for obtaining a certificate is fully online, relying on proof of domain control. This usually involves placing a random string in a URL path or a DNS TXT record (a ‘nonce’ — meaning one-time-use value), supplied by the certificate issuer. This proves that the requester controls the web service or DNS zone.
This model assumes the domain name or zone was subject to some competent authority’s checks at registration, which may have looked like the old, notarized processes. That up-front work is now offset by automated issuance, rather than repeated every time.
There’s no longer any heavyweight overhead — the process is scripted and fully online. Manual management often causes more problems than it solves. Using a tool like certbot from the Electronic Frontier Foundation and integrating it with your web or DNS service enables fully hands-off, lights-out certificate renewal.
Trust, revocation, and risk
So why shorten the certificate lifetime? The issue is trust.
Clients rely on certificates to secure transport between themselves and your service. They want two things:
- Proof of identity: This is about the certificate’s Subject Name. Strong linkage to the DNS name is now considered sufficient. The old model, which validated that you were IBM Inc. rather than just the controller of ibm.com, was aimed at a different type of assurance. Proof of possession now handles this more directly.
- Get out of trouble fast: Long certificate lifetimes make this more difficult. If a certificate is compromised, the longer it’s valid, the harder it is to contain the damage.
All certificates include a validity period — a ‘valid from’ and a ‘valid until’ timestamp. Without this, they aren’t legal certificates. They can also include revocation mechanisms, like a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP) endpoint. But in practice, many clients don’t reliably check CRLs or OCSP, or those services aren’t always online.
This means the validity window becomes the effective limit of trust. A shorter lifetime means that if you have to walk away from a certificate, the window before it becomes demonstrably invalid is reduced, bringing the risk profile down.
You could argue even six days is too long; 47 days may still be uncomfortably long, representing more than a month of potential breach. However, the 47-day limit was the result of a ballot in the CA/Browser Forum, involving Certificate Authorities (CAs) and browser vendors. It’s a step along the road towards a likely shorter standard in the future, which Let’s Encrypt has already adopted.
Final thoughts
In certificates, short lives are safer. It may feel counterintuitive, but in the PKI world — and increasingly in Resource PKI (RPKI), where the Regional Internet Registries (RIRs) are also under pressure to shorten validity windows — it’s a sound design choice.
As certificate lifetimes continue to shrink, now is the time to make sure your systems are ready. Automate where possible, and treat short-lived certificates not as a hassle, but as a path to stronger, safer infrastructure.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.