Setting the optimal Public Key Infrastructure (PKI) validity periods for certificates can be daunting and complex.
Because the implications for network security and operational efficiency are significant, organizations often find themselves caught in a tug-of-war:
- Set the validity period too long, and you risk running into compliance issues or having out-of-date certificates that no longer meet security standards.
- Set it too short, and the administrative burden spikes, increasing the likelihood of disruptions and outages.
Choosing the right validity period is influenced by a few factors, such as the type of certificate, its use case, and security best practices. In this article, we give you our recommended approach for navigating PKI decisions and avoiding certificate-related pitfalls.
Setting the right validity period – What to consider
Selecting the appropriate validity period for certificates is relatively straightforward. Simply log into your Certificate Authority (CA) management console or admin interface. Navigate to the configuration settings for certificate templates or profiles. Then set the default validity period for each type of certificate. How you determine what the validity period should be is based on several strategic considerations:
- Balancing security and lifespan
- Trade-off between key strength and computational cost
- Adapting periods to certificate types
Key length vs. computational resources
Longer key lengths are more secure but come with a trade-off in terms of the computational resources required. This is particularly important in environments with constrained resources and limited processing power, such as IoT devices.
Take, for example, RSA encryption: A 2048-bit key demands significantly more computing power compared to a 1024-bit key. The increase in resource requirement could cause latency issues that hinder or even prohibit real-time applications or devices from operating efficiently.
Alternatively, some asymmetric algorithms mitigate these computational burdens. Elliptic Curve Cryptography (ECC) grants comparable security with shorter key lengths than RSA. The added efficiency balances security demands with operational performance without compromising on system functionality. ECC is an especially apt choice for environments where rapid processing and efficiency are prioritized.
Different types of certificates, different validity periods
The exposure and usage of your certificates dictate what their validity periods should be. SSL/TLS certificates, which form the basis of internet security, typically have shorter validity periods-in fact, Google has recommended that certificate lifespans be shortened to 90 days. By keeping the period relatively short, the exposure time that a compromised certificate could be exploited is also limited.
On the other hand, code-signing certificates, which are often used to authenticate software and are less exposed to direct public interaction, generally have longer validity periods of 3 to 5 years. The extended period makes sense for this case because of the reduced risk profile; they’re not directly exposed to continual threats like face public-facing certificates.
Lastly, internal certificates, used for internal servers and applications, offer the most flexibility. The validity period for these certificates should be adjusted according to your security policies and operational risk tolerance
Revocation best practices
Revocation of certificates is also necessary for maintaining your PKI’s security. Here are some targeted practices to help you through this process:
Handling certificate expiry
When replacing a certificate that’s nearing its expiry, there’s no need to revoke it prematurely. It’s more practical to allow the old and new certificates to co-exist during the overlap period. Once the older certificate naturally expires and becomes invalid, the new certificate continues to be valid and operational-mitigating service interruptions. This practice offers seamless transition while maintaining continuous security coverage without requiring manual intervention at the point of expiration.
Responding to compromised certificates
If a certificate is compromised, misused, misconfigured, or there’s been a significant change in the certificate holder’s status (such as employment termination), active revocation is necessary. Promptly revoking these certificates negates any trust previously established by compromised certificates and prevents them from being exploited by unauthorized users
Utilizing Certificate Revocation Lists (CRL)
Certificate Revocation Lists (CRL) help manage revocation. When a certificate needs to be revoked, its serial number is added to a CRL which is a file maintained, updated, and published regularly by the Certificate Authority (CA). CRLs provide a record of all revoked certificates along with their revocation dates. Systems that need to verify the validity of a certificate can refer to these lists to avoid accepting a revoked certificate, enhancing overall security.
Implementing Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP) can also handle revocation checks. Unlike CRLs that require downloading and list checking, OCSP grants real-time status checks without having to handle large CRL files. This method reduces the latency and overhead associated with traditional CRL downloads, which is particularly useful for environments that require timely certificate status verification.
Emphasizing bulk revocation and reissuance
Scenarios where multiple certificates are compromised may require bulk revocation and reissuance. This undertaking can be managed with a certificate lifecycle management tool, which facilitates quick revocation of affected certificates along with timely reissuance of new ones.
Documentation and scaling through automation
As organizations manage more certificates with shorter validity periods, automation becomes necessary for efficient renewal. Manual tracking methods, such as spreadsheets, are too error-prone and become less and less realistic as the scale and frequency of renewals increases.
Thorough documentation is equally important, whether processes are manual or automated via a Certificate Lifecycle Management (CLM) tool.
Every certificate must be meticulously documented because it only takes one untracked expiration to cause outages and disruptions.
This documentation process is particularly challenging in environments where teams like DevOps are responsible for their certificate management and have already chosen their own tools. Comprehensive documentation across all teams and tools is needed to both prevent lapses in certificate tracking and maintain your organization’s operational continuity.
As certificate management becomes more advanced and threat actors evolve their tactics, we recommend sticking to the following:
- Always adhere to credible certificate validity best practices
- Fully embrace certificate management automation across your organization
- Maintaining thorough documentation
The future of certificate validity and security standards
As the number of cybersecurity incidents increases, so does the trend of reducing the validity periods for certificates.
Technically, organizations have the discretion to set whatever validity periods they see fit.
However, best practices are often influenced by third-party systems. Web browsers in particular lead the charge here by actively flagging certificates with questionable periods, and enforcing security practices derived from the CA/Browser Forum.
Because these widely used systems come with their own security standards, they end up pushing the industry towards shorter validity periods. This shift is expected to continue as organizations become more aware of the necessity for keeping in step with security best practices.
Combined, these crucial steps will not only prevent potential outages but also improve the management of certificates across increasingly complex IT environments.To further strengthen your security posture and streamline operations consider KeyFactor’s comprehensive certificate management solutions.