28 February 2018 marked the last day that organizations could purchase certificates with a three-year validity period. All SSL/TLS certificates issued on or after 1 March will have a maximum lifespan of approximately two years (825 days) only. This change, which reflects the Certificate Authority/Browser (CAB) Forum's adoption of Ballot 193 in February 2017, is significant in that organizations will now need to renew their certificates more often. Hashed Out Editor-in-Chief Patrick Nohe thinks all this greater frequency re-validation by CAs will increase the time involved in the re-issuing process. If that's true, organizations will need to plan ahead to make sure their protected websites don't suffer any certificate outages
At face value, shorter certificate validity periods seem like a pain. But there is a draw to renewing certificates more frequently. Security consultant Scott Helme says there are several security benefits associated with implementing shorter maximum certificate lifetimes. Here are four identified by Helme.
The Revocation Process Is "Completely Broken"
Sometimes attackers make off with the private key for a website's certificate. In other scenarios, someone at the company inadvertently exposes the key online. Either situation presents a strong case for revocation, or when an issuing CA deems a certificate no longer trustworthy.
Unfortunately, the mechanisms for revocation are what Helme calls "completely broken." The first mechanism, certificate revocation lists (CRLs), is supposed to tell browsers which certificates they shouldn't trust. But CRLs are usually large in size and broken down by intermediate CA, segmentations which make the lists hard to follow. The client (i.e. the web browser) also needs to have an updated version of the CRL. If it doesn't, it usually make a request for one during the initial connection to the site, which can as Helme describes "make things look much slower than they actually are."
Owners can also use the online certificate status protocol (OCSP) to ask a CA about a given certificate's status. In so doing, however, the client exposes a users' browsing history by inquiring about a particular site they visited. OCSP can therefore compromise users' privacy.
New Threats Are Constantly Challenging the Certificate Ecosystem
The certificate ecosystem is not static. It's constantly changing. One of the factors that drives this dynamism is 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.
Shorter validity periods allow CAs and owners to stay on top of developments such as the weakening of SHA-1 with minimal need for unscheduled re-issuing. By contrast, longer certificate lifetimes make it more difficult for the certificate ecosystem to stay current with emerging threats. This latency of action means that owners could very well be left with certificates that will stop working before they meet their expiration dates.
Private Keys Need More Frequent Rotation
Organizations want to avoid a key compromise. However, they recognize that such an incident can still occur. Many therefore decide to rotate their cryptographic keys. Doing so reduces the material encrypted with a single key, thereby minimizing the potential impact of a single key compromise.
Key rotation requires that organizations use a different key with their certificate. Such a change necessitates re-issuing a certificate. That's not much of a concern with shorter validity periods; enterprises can simply time the rotation of their keys with their certificates' expiration dates. In the event of longer certificate lifetimes, however, organizations must take the time and spend the money to request that CAs reissue their certificates prematurely.
Long Validity Periods Make Log Disqualification More Likely
Beginning in the spring of 2018, a new requirement called Certificate Transparency (CT) will require all CAs to log their issued certificates into public and auditable logs. Certificates will need to 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.
What Can Organizations Do in the Meantime
Helme is optimistic that the CAB won't stop at Ballot 193 and will introduce new proposals that make certificate validity periods even shorter than 825 days. His hopes aren't unfounded. The CAB voted on and passed Ballot 193 only after Google introduced its own ballot that would have reduced certificates' lifetimes to just 13 months. CAs and other browsers largely opposed the ballot and caused it to fail. When they did, Google’s representative Ryan Sleevi suggested that the tech giant may pursue other means to get its way. Google could, for instance, set certificate trust requirements in Chrome to just 13 months.
If Google's determination is any indication, certificate lifetimes will likely continue to shrink. This frequency of renewal will place increasing strain on organizations that manually monitor their certificates until it becomes impossible. With that said, enterprises should get ahead of the curve by automating their certificate management process.