The CA/Browser Forum has recently approved a significant change to the maximum validity period of TLS certificates, reducing it to just 47 days by March 2029. This decision marks a pivotal shift in the management of digital certificates, emphasising the need for robust automation to handle the increased frequency of renewals.
The New TLS Certificate Lifetime Schedule
According to recent updates from Digicert and The SSL Store, the reduction in TLS certificate lifetimes will be implemented in phases:
- 15 March 2026: Maximum certificate lifetime drops to 200 days.
- 15 March 2027: Maximum certificate lifetime further reduces to 100 days.
- 15 March 2029: Maximum certificate lifetime reaches 47 days.
Additionally, the period during which domain validation information can be reused will also decrease, reaching just 10 days by 2029.
Why 47 Days?
The choice of 47 days might seem arbitrary, but it is designed to align with practical renewal cycles and ensure certificates are always based on up-to-date information. Shorter lifespans contribute to the reduction of the risk of compromised private keys, domain hijacking, and mis-issued certificates.
You may also have read about proposals to move to 90 day certificates from Google over the last few years. This proposal has been withdrawn and the CA/B Forum community has settled on Apple’s proposal for 47 day certificate lifetimes.
The Importance of Automation
As the validity period of TLS certificates shortens, the workload for certificate lifecycle management (CLM) will increase significantly. By 2029, organisations will need to renew certificates approximately every six weeks, compared to the current annual cycle. This shift implies the adoption of automation to manage the frequent renewals efficiently and cleanly.
Phased Introduction of Automation
Implementing automation in a phased manner is crucial for several reasons:
- Gradual Adoption: Organisations can gradually adapt their systems and processes to handle the increased renewal frequency. This reduces the risk of disruptions and ensures a smooth transition.
- Enhanced Security: Automation minimises human errors and ensures that certificates are renewed promptly, maintaining the integrity and security of the digital infrastructure.
- Cost Efficiency: While the initial setup of automated systems may require investment, the long-term benefits include reduced operational costs and improved efficiency.
- Preparation for Quantum Computing: Shorter certificate lifetimes and automation prepare organisations for the advent of quantum computing, which will require rapid adoption of stronger cryptographic algorithms.
Non-trivial systems
You will, doubtless, have some systems or services that do not fit nicely into the automation options available.
Hybrid issuance and deployment
As an interim measure, you may be able to use a tool intended for automation (such as certbot, dehydrated, or win-acme) to request new certificates but then have a manual process of deploying the requested certificate/keypair to the desired system. This is likely to require the use of the DNS-01 challenge mechanism as you’re unlikely to be able to use HTTP-01 in this scenario. You should take care with how you move the private key material around between systems to ensure you don’t leave the sensitive data in inappropriate places!
Use a reverse-proxy
For some use-cases, you may be able to put an extra layer in front of a troublesome system or service which you can automate. This could be, for example, nginx or Caddy in front of a HTTP web based service. Other protocols may require more complex arrangements such as using stunnel.
Long term changes to procurement or project management approach
You may wish to consider how future-proof your systems and services by ensuring that project briefs, or procurement documents include requirements covering the automation processes you wish to use and, also, to feed these requirements back to your existing suppliers so that they can make preparations ahead of any contract renewals.
Internal Certificate Authority
Another option for some internal and well scoped use-cases could be the deployment of an Internal (or “Private”, or “Enterprise”) Certificate Authority (CA). The CA’s identity could then be trusted by (deployed to) some of your managed devices. This CA could then be used to issue longer-lived certificates for use on systems or devices wholly managed by your engineering teams.
There are plenty of caveats with this approach and we would not recommend you use this for production or user-facing systems or services as the likelihood of users getting the dreaded Certificate Warnings in browsers is greatly increased. It can, however, provide a useful internal-only method of reducing the rollover churn for things like network switches or firewall appliances.
Please get in touch if you’d like further advice or guidance on this via certificates@jisc.ac.uk .
Conclusion
The upcoming changes to TLS certificate lifetimes represent a significant evolution in digital security practices. By reducing the maximum validity period to 47 days, the CA/Browser Forum aims to enhance the reliability and resilience of the global Web PKI. The phased introduction of automation is essential to manage the increased workload and ensure a smooth transition, ultimately leading to a more secure and efficient digital ecosystem.
Are you interested in learning more about how to implement automation for certificate management in your organisation? Please get in touch via certificates@jisc.ac.uk.
