When Let’s Encrypt issued its first 90-day certificate on September 14, 2015, the industry standard was a three-year certificate validity period. Since that time, the mandated lifespan has been reduced to two years in 2018 and then to one year in 2020. The original justification from for the 90-day certificate lifespan was that:
- They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.
- They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenient than longer ones.
And now Google is jumping on the 90-day wagon. In March of this year, the Chromium Project released a “Moving Forward, Together” roadmap, where Google announced that it intended to move to a 90-day certificate. Given the market share of Google Chrome, this policy change would essentially force the hand of the CA/B Forum to put forward a Ballot Proposal to ratify the shorter certificate lifespan. As Dark Reading points out, “Browsers control their own root program requirements, so browser makers don't have to wait for formal rule changes from the CA/B Forum.” In fact, this is exactly how Apple strong armed the change to a one-year certificate validity period.
While Google did not provide a timeframe for the recommended change, many experts believe that the new validity period will likely take effect by the end of 2024. This change is significant in that organizations will need to be prepared to renew their certificates much more often—4 times a year more often. Many security experts fear that this change will cause complexity involved in the re-issuing process and increase instances of certificate-related outages.
In reality, the only organizations that should be worried are the ones with no visibility or control over their machine identities. If you have embraced automation and have a thorough knowledge of your keys and certificates, these shorter certificate lifecycles are a good thing.
What is the typical SSL certificate validity period?
Every certificate has a predefined validity period that is expressed in terms of a fixed start date and time and a fixed end date and time. The validity period of an SSL certificate cannot be changed after the certificate has been issued. And once a certificate expires, the software or website will be unable to use it to authenticate communications and will refuse access, causing application outages and major operational disruptions.
For SSL certificates, the validity period generally conforms to recommendations given by the CA/Browser Forum, which is made up of representatives from certificate authorities (CAs), internet browser providers and other industry experts.
Certificate validity periods can be slightly different, depending on the type of certificate, and the issuing CA. While an SSL certificate is valid for just over a year, code signing certificates are valid for up to three years. However, as mentioned above Let’s Encrypt certificates are even shorter than the CA/B Forum recommendations, with a validity period of just 90 days.
What is the maximum SSL certificate validity period?
The validity period of SSL certificates is currently set at 398 days, or about 13 months. CA/B Forum recommendations state that SSL certificates cannot be issued for more than that period (13 months or 397 days). So, they must be renewed within that timeframe to remain valid.
In general, maximum certificate validity periods impact the security of applications or websites using them in two ways. Shorter lifespans encourage more frequent updates and limit potential exposure if a certificate is compromised. We’ll talk in more depth about these advantages in the following section.
Why are shorter certificate validity periods better?
Shorter certificate validity periods may seem like an invitation for more repetitive work, but this doesn’t necessarily have to be the case. Security consultant Scott Helme says there are several security benefits associated with implementing shorter certificate lifetimes. Here are four identified by Helme:
Don’t Delay: 5 Urgent Actions to Prepare for 90-Day TLS/SSL Certificates
1. The revocation process is "completely broken"
The sad truth is that hackers do sometimes make off with a website’s private keys, former disgruntled employees may maliciously expose the key online, and active employees accidently expose a company’s network. These situations are just some of the reason’s organizations implement revocation, when an issuing CA deems a certificate as no longer trustworthy. Unfortunately, Helme considers the mechanisms for revocation "completely broken."
The main mechanism being certificate revocation lists (CRLs), which communicate to browsers which certificates they shouldn't trust. CRLs are usually very large and broken down by intermediate CA, segmentations which make the lists difficult to follow. The web browser also needs to have an updated version of the CRL. If it doesn't, it will usually create a request for one during a user’s initial connection to the site. Helme explains that this delay can"make things look much slower than they actually are”, possibly hurting your page speed and bounce rate (two highly significant SEO factors).
Owners can also use the online certificate status protocol (OCSP) to ask a CA about a given certificate's status. But doing this exposes a users' browsing history and compromising their privacy.
Because revocation status relies on the CA infrastructure, organizations are still left on their own if revocation status cannot be checked. They can choose to “fail open” and proceed with the transaction and risk missing a compromised certificate was marked as revoked. Or they can choose to “fail closed” where they block the transaction altogether and compromise business continuity.
Because shorter lifespans reduce both validity and exposure, some organizations simply choose not to check revocation status at all—relying instead the frequent rotation of short-lived certificates.
2. New threats are constantly challenging the certificate ecosystem
The certificate ecosystem is not static. It's constantly changing, in large part due to the appearance of new threats.
Take SHA-1, for example. CAs used to rely on the hash algorithm to generate certificate signatures. But then the algorithm got older and weaker, eventually forcingChromeand other web browsers to no longer trust SHA1-signed certificates back in 2015. In August 2020, a new malware emerged that targets SSH certificates.
With longer certificate lifespans, there was often a tendency to set and forget certificates. Extended inactivity could lead to certificates becoming compromised before reaching their expiration dates. And with less engagement in the dynamic certificate ecosystem, there was a greater potential that certificates would be exposed to emerging threats.
Shorter validity periods encourage CAs and owners to remain vigilant and up to date with threat developments, thereby minimizing the necessity for unscheduled re-issuing.
3. Private keys need more frequent rotation
Organizations obviously want to avoid a key compromise but recognize that these incidents are always possible. Many organizations will frequently rotate their cryptographic keys, reducing the potential exposure of repeated key reuse. If keys are not properly rotated and are being used over and over to encrypt a variety of data, there is an increased risk of that data being compromised through a hacker cracking that singular key just once.
Key rotation requires that organizations use a different key with their certificate, and such a change necessitates re-issuing a certificate. Shorter validity periods increase the frequency of key rotation as enterprises can simply time the rotation of their keys to coincide with their certificates' expiration dates. With longer certificate lifespans, organizations who wished to implement more frequent key rotation would spend extra time and money to manually request that CAs reissue their certificates mid-lifespan.
4. Long validity periods make log disqualification more likely
Certificate Transparency requires all CAs to log all issued certificates into public and auditable logs. 398-day certificates must contain at least three Signed Certificates Timestamps (SCTs) from three independent logs to qualify for CT logs. If a certificate doesn't contain those three SCTs, then it won't be CT qualified and will therefore be rejected by the browser.
The problem is that certificate logs can disqualify during the lifetime of a certificate. And the longer the certificate lifespan, the greater the chance that a log failure which happens when a previously issued certificate stops working and requires replacement prior to its natural expiration date.
Longer certificate lifespans require more SCTs to minimize the probability of a log failure. Certificates with shorter validity periods make it safer to include fewer SCTs just as they make log disqualifications less likely. For example, 180-day certificates would only require 2 SCTs.
Automation is the solution to shorter certificate lifespans
Historical patterns suggest that the duration of certificate validity will likely continue to diminish. Google is already pushing for 90-day certificate lifespans, down from the current 1-year (398 days) lifespans. And there’s still every chance that the lifespan could become even shorter. As this trend persists, organizations will be managing 4x-6x more certificates per year. With higher volumes of certificates, the burden on organizations that manually track their certificates will escalate to an unsustainable level. It is clear that shorter certificate lifespans enhance security, yet the feasibility of managing this within the present certificate landscape hinges on automation and comprehensive network oversight.
However, the benefits of automation extend beyond security. It represents a streamlining of procedures and a significant reduction in manual labor. This not only boosts efficiency but also curtails the likelihood of human errors, which subsequently diminishes the risk to security. A great plan of action is to start integrating automation into your certificate management processes now so you don’t have to worry about it later.
(This post has been updated. It was originally published on June 18, 2021)