When a private key gets compromised or an organization shuts down, the affected digital certificates should no longer be trusted. The reason is simple: Those certificates now either contain a compromised key or were issued to an organization that no longer exists.
That’s where certification authorities (CAs) step in—they revoke, or invalidate, these certificates to signal to users that they’re no longer safe.
But the revocation process is complex and time-consuming. That means an untrustworthy certificate could still be floating around before its revocation is complete, leaving the compromised certificate open to exploitation from attackers.
Certificates with short lifespans could be the answer, but they come with their own challenges. Let's look at how short-lived certificates work and what managing them means for organizations.
Revoking a certificate isn’t as simple as pushing a button. Sometimes, it takes weeks or even months to discover that a key has been compromised or that an organization is no longer around. Once these issues come to light, the CA then needs to confirm them. This could mean running technical checks to verify a compromised key or checking business records to ensure the organization has actually shut down. After that, the CA revokes the certificate by adding it to a certificate revocation list (CRL) and updating its online certificate status protocol (OCSP) responder to show that the certificate is no longer valid.
Next comes the tricky part—users have to retrieve this updated information by downloading the CRL or OCSP response. But network issues or other failures sometimes prevent users from getting that updated status right away. When that happens, their software has to make a tough call: Should it trust the certificate or treat it as untrusted? If the software continues using the certificate, there’s a chance attackers could exploit that gap, forcing users to rely on compromised certificates.
To make things more complicated, some major browsers repackage CRLs in their own format, potentially leaving out certain revoked certificates they deem less critical. This adds another layer of risk, where users might unknowingly trust certificates that have already been revoked.
Given how complex and slow the revocation process can be, standards bodies have proposed an alternative: short-lived certificates. These certificates are designed to expire before there’s even a need for revocation. Since their validity period is shorter than the time it typically takes to revoke a certificate, they simply expire on their own, making revocation unnecessary.
This approach offers benefits for both users and CAs. Users no longer have to worry about downloading updated revocation information, and CAs can skip the time-consuming tasks of processing revocation requests and publishing revocation data.
Managing long-lived certificates manually is already a challenge, and adding short-lived certificates into the mix only increases the complexity. Imagine having to renew certificates every week or two by hand—without automation, it would be tedious, error-prone, and nearly impossible to scale.
To fully tap into the benefits of short-lived certificates, organizations need to automate the entire certificate lifecycle. By doing so, they can streamline the process and enjoy the operational simplicity short-lived certificates are designed to offer.
In June of 2024, the Internet Engineering Task Force (IETF) introduced RFC 9608: No Revocation Available for X.509 Public Key Certificates. This standard lets CAs flag certificates as short-lived, which tells users there’s no need to download revocation information. The presence of this extension in certificates simplifies things for user applications, which can just check for the extension to determine if revocation data even needs to be downloaded from the CA.
And in 2023, the CAB/Browser Forum’s server certificate working group passed ballot SC-63, allowing CAs that issue publicly trusted TLS certificates to skip including revocation information for certificates valid for less than ten days.
DigiCert and several other CAs have long supported short-lived certificates in the TLS ecosystem, so we’re glad to see this change in the Baseline Requirements. But one hurdle remains—Microsoft’s root policy still requires OCSP pointers in all TLS certificates, even those that are short-lived. Until we overcome this hurdle, organizations may face limitations in fully embracing the simplicity and efficiency that short-lived certificates can offer.
Still, the progress toward widespread short-lived certificate adoption is clear. And as more industry leaders push for crypto-agility and streamlined certificate management, we’ll see even more progress toward broader adoption and support.
As short-lived certificates gain traction, crypto-agility—the ability to quickly adapt to changing cryptographic standards—is becoming more important than ever. Short-lived certificates are a highly effective way to enhance security, but their frequent renewal cycles and shorter lifespans require organizations to be flexible and efficient in managing their certificates.
Crypto-agility ensures that organizations can seamlessly switch to new algorithms or standards without disrupting operations, which is essential when dealing with certificates that may be issued, expired, and reissued within a matter of days. This agility is particularly important in response to emerging threats like quantum computing or when implementing updates to cryptographic protocols.
DigiCert Trust Lifecycle Manager was built with crypto-agility in mind, providing organizations with the tools they need to automate certificate management, adapt to new security protocols, and deploy short-lived certificates at scale. As the use of short-lived certificates grows, having a crypto-agile infrastructure will be crucial for maintaining both security and operational efficiency.
Want to learn more about topics like crypto-agility, certificate lifecycle management, and automation? Subscribe to the DigiCert blog to ensure you never miss a story.