PKI helps encrypt and secure communications on the internet but is a complicated field that takes specialized training to master. The management of keys and certificates necessary for PKI to function properly is a tedious task and unfortunately, many IT professionals disregard published best practices. One mistake frequently made is associated with the rotation of PKI certificates and keys.
Certificate Validity Periods
In the beginning a CA was not limited in what validity period it could place on a certificate that it issued. Back in the late 2000's GoDaddy would issue a certificate that was valid for 10 years! While this seems like a great idea, since you save all the hard work of renewing your certificates, it really isn't for many reasons.
The first restrictions on the maximum validity period of a certificate came with the establishment of the CA/Browser Forum and their Baseline Requirements document. The CAB Forum is the body that governs how CAs must issue and manage publicly trusted certificates through the rules set out in the Baseline Requirements (BR). The first version of the BR, adopted on 22 Nov 2011 and effective from 1 Jul 2012, introduced the first certificate validity limit. Section 9.4 of that document states that “Certificates issued after the Effective Date MUST have a Validity Period no greater than 60 months.” That was quite an improvement, but it didn’t last for long.
Three years later, the validity period would be set down to 39 months. Per the 2015 version of the BR “Except as provided for below, Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months.” In 2017 the CAB Forum proposed to lower the validity period down to 398 days, but that proposal did not pass and was met with wide resistance from all but one of the CAs that voted. Following the failure of the ballot to reduce the maximum age to 398, the Forum proposed a new ballot in March 2017 to try and reduce the maximum age to 825 days instead, which was successful.
From March 2018 all newly issued certificates will be limited to a maximum validity period of 825 days. (Google and others are still pushing for 398-day validity periods.) This is a great step forward for the security of the wider web. Having a clear view on where we currently stand with certificate validity, let's take a look at why we need to reduce the validity period on certificates and what benefits doing so would bring.
Why we need short certificate lifecycles
Determining the certificate validity period is more than just determining when your certificates will expire, which of course is of great importance. Although shorter certificate validity periods require more effort to renew them more frequently, there are some serious security benefits to reducing the lifetime on the certificates you get.
Concurrence with cryptographic advances
Over time, protecting long-lived certificates and keys becomes harder as more powerful computers will eventually compromise the cryptography of the present leading to cryptography standards being eventually superseded. Eventually a broken algorithm may cause an urgent need to replace certificates for continued security. So here is our first benefit. Longer certificates need to be replaced less frequently but can eventually become outmoded as new algorithms and ciphers come into favor. There are constantly new threats that as a wider industry we need to respond to and, therefore, we need to be able to flush the whole ecosystem of all existing certificates much faster.
By choosing longer validity periods, we end up with a broader range of certificates and their private keys that need to be kept safe. This increases your attack surface, making your certificates and keys an attractive target for malicious actors seeking to compromise a certificate, since it gives them access for longer periods. This, in turn, increases the importance of having a revocation system, and makes it necessary to retain revocation information for longer periods—resulting in larger revocation files and more network activity. On the other hand, if you hold certificates with short validity period, the damage done will be less, since the attacker will have less time to abuse your compromised certificates. This forces the attacker to act more quickly, he is a threat for a much shorter time frame and overall your users will face a considerably reduced amount of risk.
Scott Helme provides one more justification for shorter certificate validity periods. Certificate Transparency (CT) requires all CAs to log all certificates they issue into public and auditable logs. This enforces transparency into the operations of any CA, and no one will be able to obtain a certificate for your domain without your knowledge. To be CT qualified a certificate has to contain at least 3 Signed Certificate Timestamps (SCT) from 3 independent logs. If a certificate does not contain 3 valid SCTs then it won't be considered as CT Qualified and the browser will reject it. The longer a certificate is valid for, the more likely it is a log disqualification could happen and that the certificate would fail CT qualification and be rejected. Shorter certificates help to protect against this being a problem.
It’s critical to consider not only the validity period of your certificates, but also the method for replacing them. There are far too many security trade-offs in attempting to use a single certificate for the lifetime of the device. We want frequent renewals but as you get more certificates it becomes harder to do it manually. This is why automation is essential and comes with many benefits. Removes the risk of missing a renewal, removes the risk of human error, reduces the cost involved in obtaining and renewing certificates. Automation helps also increase your visibility of your assets.
The expiration of a certificate provides a great opportunity to rotate the key that's in use with that certificate. Therefore, short certificate validation helps you establish good hygiene practices in rotating keys.
NIST calls “the time span during which a specific key is authorized for use by legitimate entities” a cryptoperiod. According to NIST SP 800-57 part 1 rev. 4, “A suitably defined cryptoperiod limits the amount of exposure if a single key is compromised, limits the time available for attempts to penetrate physical, procedural, and logical access mechanisms that protect a key from unauthorized disclosure, limits the period within which information may be compromised by inadvertent disclosure of keying material to unauthorized entities, and limits the time available for computationally intensive cryptanalytic attacks.” The length of a cryptoperiod is defined by various factors, such as the operating environment, the classification and volume of protected data, the personnel rotation, etc.
Based on the aforementioned criteria, NIST recommends that the maximum cryptoperiod of private keys associated to certificates should be between one and three years and should be shorter than the cryptoperiod of the corresponding public key. Scott Helme says that “you should rotate your private keys at least every year” and doing otherwise “is bad hygiene and the longer a given cryptographic key is in use the more likely it is to face compromise.”
Designing a safe PKI is about figuring out what’s best for your organization. You’ll need to come up with an entire plan that covers not just the initial roll out but the entire certificate lifecycle. Creating a strong PKI that considers the technical needs of your product, creates a strong security foundation for your devices and network and builds confidence and trust for your customers. When it comes to certificate and key validity, follow the industry recommendations and opt-in for shorter periods. Use automation solutions, such as TLS Protect Cloud to help you minimize the tedious task of managing your certificates lifecycle.