Get ready for the 90-day change FAQ roundup! You might have heard that Google have signalled their intent to drive through the reduction from 398-day to 90-day certificate lifecycles, as the new standard.
The timeline for this change is not yet clear. However, Certificate Authorities such as Sectigo, GlobalSign and Digicert have been advising people to prepare for it to be accepted, and to get ahead of the change.
We’ve been flooded with enquiries over the past few months, so here are answers to some of your most frequently asked questions.
Q1. Will it eventually end up as 1 day … or even 1-hour certificates?
A: As cyber security threats continue to advance, we cannot rule out the possibility of further lifespan reductions. However, with robust automation in place, it shouldn’t pose a challenge. That is why we are encouraging everyone to get a head start now. While we cannot predict the future two years down the road, what we do know is that preparation is key. As the saying goes, “Fail to prepare, prepare to fail.” Implementing automation now is a proactive step towards future readiness.
Q2. Have Google Indicated if Chromium based browsers will expect a 90-day lifetime for all certificates including from internal CAs?
A: As of now, Google has outlined its vision for reducing the validity period of certificates to 90 days within the Chromium-based browsers. While their primary focus appears to be on certificates across the board, including those from internal Certificate Authorities (CAs), specific details on this aspect may not have been explicitly communicated. It is recommended to stay tuned for further updates from Google or consult their official communications for any specific guidance regarding the lifetime expectations for certificates issued by internal CAs within Chromium-based browsers.
Q3. Are there any disadvantages to using LetsEncrypt (or equivalent) for public servers?
A: There are several elements you should consider when determining what type of certificate, and certificate provider, to use. The first thing to consider are the different use cases for your certificates.
Let’s Encrypt only offers domain or DNS validated certificates. It does not issue Organisation Validation (OV) or Extended Validation (EV) certificates, focusing solely on domain ownership validation. This means they do not verify the legal entity requesting the certificate is actually who they claim to be.
According to Sectigo, ‘because the legitimacy of the organization is not vetted, they are not recommended for business websites but are ideal for internal sites, test servers, and test domains’.
Furthermore, Let’s Encrypt doesn’t provide any warranties in the event of data leakage. This may be a concern for organisations seeking additional assurances. You can learn more about different types of SSL certificates and their recommended applications here.
A notable benefit is that the service from Let’s Encrypt is currently free. Let’s Encrypt imposes a primary rate limit of 20 certificates per registered domain per week but there are no restrictions on the number of renewals. This offers a level of flexibility in certificate management.
However, due to its domain validation nature, there are no additional checks on the owner of the domain or website, potentially posing challenges for those requiring a more comprehensive validation process.
Ensuring full uptime and reliable support from your chosen certificate provider is also mission critical. Let’s Encrypt provides no direct service support to its users unlike established CA providers that guarantee a level of service support. This may or may not be acceptable, depending on your use case.
Another consideration is whether you wish to have certificates issued by multiple providers, across your estate. This can lead to increased risk, however there are ways to make this type of hybrid certificates management easier. For example, with Sectigo’s Network Discovery tool.
Ultimately, you must decide what level of risk is acceptable for your organisation and use case.
Q4. Presumably the certificate automation process is only for the renewal and NOT actually deploying; installing the new certificates which is still a manual process? Even for local AD certificates?
A: The installation of SSL certificates can generally be automated. Automation simplifies the process, reduces the risk of human error, and ensures that certificates are consistently and promptly deployed. Several tools and protocols facilitate the automation of SSL certificate installation, including ACME, CertBot & Ansible.
However, we know some systems may not work well with these generic protocols; requiring different integrations/plugins, and in some cases – bespoke workarounds. Jisc are actively seeking guidance and solutions to address these more problematic use cases, for our members and customers. We aim to update you on this in early 2024.
Q5. Automating some of our systems, such as load balancers or reverse proxies, would likely require bespoke work. If things go wrong during any sort of automation (which it will), the disruption would be immense. What do we do?
A: We understand that not all systems can seamlessly transition to an automated approach. If you are likely to require specialized support beyond the standard ACME/Certbot/Ansible solutions, do not hesitate to reach out with these requirements. This allows us to factor your feedback into our service development plans.
This is one of the many reasons we think it’s important for you to get ahead of the change, and start testing automation sooner rather than later. A proactive approach allows room for potential hiccups with test certificates, ensuring a smoother transition when the 90-day implementation date rolls around.
In the wise words of Mark Twain, ‘the secret of getting ahead is getting started’.
And that’s a wrap! If this has been a helpful read, make sure to keep an eye out for further updates coming soon about the automation guidance and support that we’re developing.
If you have any feedback or questions in the meantime, please contact the service desk via certificates@jisc.ac.uk