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:
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. It’s clear that depending on these mechanisms alone is not sufficient.
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.
Shorter validity periods compel CAs and owners to stay on top of threat developments and reduce the need for unscheduled re-issuing. On the other hand, longer certificate validity periods make it easy for CAs to lose touch with the ever-changing certificate ecosystem and fall prey to new threats. This lack of action for extended periods of time could result in certificates going dark well before their expiration dates.
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 material encrypted with a single key and minimizing the potential impact of a single key compromise.
Key rotation requires that organizations use a different key with their certificate, and such a change necessitates re-issuing a certificate. Shorter validity periods eliminate these concerns; enterprises can simply time the rotation of their keys to coincide with their certificates' expiration dates. Longer certificate lifetimes require organizations to take the time and money to request that CAs reissue their certificates far more frequently.
4. Long validity periods make log disqualification more likely
Certificate Transparency requires all CAs to log all issued certificates into public and auditable logs. 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. In Helme's view, the longer the validity period of a certificate, the greater the likelihood that a certificate could encounter a log disqualification.
CAs can protect against these events by placing more than three SCTs inside of a certificate. But that often makes the certificate needlessly large. Certificates with shorter validity periods make it safer to include fewer SCTs just as they make log disqualifications less likely.
Automation is the solution to shorter certificate lifespans
If past trends are any indication, certificate validity periods will likely continue to shrink. This frequency of renewal will place increasing strain on organizations that manually monitor their certificates until it becomes impossible. Shorter certificate validity periods are undoubtedly more secure, and with automation and full network visibility is the only way to navigate the current certificate ecosystem. 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)
Related Posts
