4 Reasons Shorter Certificate Validity Periods Are a Good Thing
4 Reasons Shorter Certificate Validity Periods Are a Good Thing
28 February 2018 marked the last day that organizations could purchase certificates with a three-year validity period, and 31 August 2020 was the last day organizations could purchase certificates with a two-year validity period. All SSL/TLS certificates issued on or after 1 September 2020 have a maximum lifespan of approximately 13 months, a 51% reduction. This change is significant in that organizations will need to renew their certificates more often. Many security experts, including Hashed Out Editor-in-Chief Patrick Nohe, 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.
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:
-
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”, possible 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.
-
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 forcing Chrome and 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 reduces 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 pretty to new threats. This lack of action for extended periods of time could result in certificates going dark well before their expiration dates.
-
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.
-
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.
Related Posts
Like this blog? We think you will love this.
What Are SSL Stripping Attacks?
A bit of history The creator of SSL strip vulnerability is Moxie Marlinspike, a well-kn
Read More
About the author
David Bisson
David is a Contributing Editor at IBM Security Intelligence.David Bisson is a security journalist who works as Contributing Editor for IBM's Security Intelligence, Associate Editor for Tripwire and Contributing Writer for Gemalto, Venafi, Zix, Bora Design and others.
Read Posts by Author
