Certificate Validity Periods
Wherever possible, require certificate validity periods of one year to reduce security exposure to administrative turnover.
What is this?
A certificate validity period is the time between when a certificate is issued and when it will expire. Typical validity periods are between one and three years. Creating a standard for maximum validity periods enables organizations to assure that certificates and private keys are changed often enough to minimize security risk.
Why should I care?
The tradeoff with validity periods is between administrative overhead and security. Most organizations want to use longer validity periods because they simply can’t keep up with the renewals each time certificates are about to expire.
Typically, your biggest security risk is not related to key length, since you shouldn’t be using key lengths with a potential factoring or brute-force timeframe that are anywhere close to typical validity periods. For example, typical validity periods are 1-3 years. If you’re making your decisions about which validity period to select based on how quickly somebody could factor, you’re betting that the attacker can’t afford to buy three times more hardware to perform the attack. With state-sponsored attacks increasing, you just can’t afford to be using key lengths with that sort of razor thin margin. You should always assure you’re using key lengths that require several orders of magnitude to break than any possible validity period you would select.
The bigger security risk to consider when standardizing validity periods is administrative turnover and direct access to the private keys associated with the certificate. If your organization is like most others, your administrators have direct access to private keys (e.g. they can make copies of them). That means if they leave in a disgruntled fashion, they have the potential of using those private keys for malicious purposes (eavesdropping on confidential communications or unauthorized authentication into mission critical systems).
As an ideal best practice, certificates and private keys should be replaced and revoked each time an administrator with direct access to the private key is reassigned or leaves your organization. Unfortunately, this isn’t a realistic possibility for most organizations as they have enough trouble just changing certificates when they’re about to expire.
Validity periods can serve as a forcing function to require that certificates and private keys be replaced on a regular basis to account for administrative turnover—basically reducing the size of window within which somebody could maliciously use a private key that they have unauthorized access to.
What should I do?
Simply put: Wherever possible, require one year Validity Periods and, where warranted, require that certificates and private keys be replace whenever an administrator is reassigned.
If you agree that your biggest risk with Validity Periods is administrative turnover, most organizations have at least one person leave during a one year period. A one year Validity Period gives you the best shot of minimizing your exposure to a disgruntled employee. Your administrators may squawk that they simply can’t keep up with annual certificate rotations, you should look at an automated way of rotating them.
For applications where data is extremely sensitive, you should augment the one year Validity Periods with the requirement that certificates and private keys be changed each time an administrator is reassigned, especially if there are doubts about whether that administrator may try to do something malicious or damaging to your organization.
