Skip to main content
banner image
venafi logo

4 Reasons Shorter Certificate Validity Periods Are a Good Thing

4 Reasons Shorter Certificate Validity Periods Are a Good Thing

why-shorter-certificate-validity-periods-are-good
June 18, 2021 | David Bisson

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:

  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”, 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.

  1. 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.

  1. 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.

  1. 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.
let's-encrypt-root-certificate-expiring
Featured Blog

Let’s Encrypt Root Certificate Expiration: Will You Be Impacted?

This is not an isolated problem.

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

TLS MIM For Dummies
eBook

TLS Machine Identity Management for Dummies

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

David Bisson
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
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more