Q&A on 47 Day Certificates. You asked – Sectigo Responds!
The topic of short-lived 47-day certificates is a major one for the cybersecurity industry.
The topic of 47-day certificates represents a recent market-disrupting discussion started by Google. Last month, in its “Moving Forward, Together” roadmap, the Google Chrome root store announced its intention to reduce the maximum possible validity for public SSL/ TLS certificates days to 47 days in a future policy update or a CA/B Forum Ballot Proposal.
While it’s unclear when this new policy will go into effect, it’s expected to be by the end of 2024.
For CISOs and their teams, this step toward even shorter certificate lifespans represents a significant change in how they will approach establishing digital trust. This makes it essential to understand what these certificates are, what they mean for your business, and how this will impact SSL certificate management.
What are 47-day SSL certificates?
47-day certificates are SSL/TLS certificates that are only valid for 47 days, to meet Google’s possible future requirements. Previously, the maximum validity for certificates was 398 days. One of the main goals of reducing the certificate lifetime is to promote automation of the issuance, and reissuance, process, eliminating common errors and certificate lapses. This will, in turn, allow businesses to adapt to new cybersecurity measures and transition to hybrid and quantum-resistant certificates in the future.
So what does this mean for you?
In a recent webinar, Sectigo’s Tim Callan and Nick France discussed the ramifications of 47-day certificates. During this session, we received many questions from our customers and partners - too many to respond to at the time. You will find the answers to these questions below. To learn more, contact the Sectigo team.
Question | Sectigo’s response |
What is Sectigo’s stance on Chrome’s proposal? Has there been any pushback whatsoever from the CA’s? | The trend of shrinking certificate lifespans, or “short-lived certificates,” is one Sectigo predicted as far back as 2019. At Sectigo, we agree that the benefits of short-lived certificates are clear and concur with Google’s assessment that these changes will help improve the overall security of the ecosystem. |
How will this impact SSL certificates that are used for AS2 Signing/Encryption payload certificates that cannot be automated? | If they are public-root “SSL certificates” (server authentication) then they are affected by this change, and their lifespans will be reduced to 47 days. If they truly cannot be automated, then the manual process of revocation and issuance will still need to happen. However, the burden of system administrators carrying this out five or six times a year should not be underestimated. |
Do you think that the push for shorter certificates is going to cause pain to software vendors, forcing them to implement certificate automation (ACME for example) into their software? | Yes. One of Google’s main pillars in its “Moving Forward, Together” roadmap is focused on automation. Specifically, the roadmap lays out Google’s intention to encourage the use of automation, and highlights ACME as core to the automation of digital certificate lifecycles. |
What benefits does Sectigo provide over Let's Encrypt once we get to 47-day automated certificates? | A number of things, notably: A full certificate lifecycle management solution with a GUI, APIs, and a raft of features including:
Additionally, Sectigo can provide support and SLAs that LE does not. Sectigo is a Let’s Encrypt supporter, but we know that many customers require something more than an ACME-only service with community-based support. |
What do we do if we have the same certificate installed on multiple systems and clouds? How do we automate? E.g., we use Azure Key Vault, AKS Secrets, AWS ELB/ALB, etc. | This depends on the requirement for “same certificate”. The same subject can be issued into many certificates, and each system has its own certificate with its own unique key. The domains (SANs) and other information are the same. You essentially have multiple copies of the certificate on every system. However, if your requirement is to maintain the same exact key across all systems (which would be a poor design choice) then you would need to implement mechanisms to securely transport the key material around the systems, which is difficult to do safely and increases risk. |
What is a CRL? | CRL stands for ‘Certificate Revocation List’ - a cryptographically-signed list of serial numbers for certificates that have been 'revoked' or canceled by the CA or user. |
This impacts far more than web applications accessed via web browsers. There will be enormous impact to communication protocol software. Many comms certificates have to be manually installed by end users at the connection profile level. These certificates require 30-47 days customer notifications. So, 80 days is the best case scenario. Do you really think comms software vendors can revamp their software and get all their customers to upgrade their software before the end of 2024? There are end users still running off Windows XP today. | The reality is if the communication software vendors require the use of publicly-trusted certificates in their systems - they will have no choice but to adapt to this change. It isn't optional and there will be no carve-outs for vendors insisting on using old and insecure technologies. Private (internal) CAs could be an option where these rules don't apply, but they require complete control over the entire ecosystem - clients and servers - so that private root certificates can be trusted. |
One of the concerns I have is appliances that do not necessarily have the means for automatic renewal. Attempting to manage SSL on those systems will not be feasible with a 47-day lifespan. Are any proposals offered to deal with that issue? | You are correct that software and appliance vendors will need to begin work to offer APIs and better automation for certificates. Those that do not will be requiring their customers to manually renew certificates every 47 days, or looking at hacks and shortcuts that will not be practical or stable. We encourage these software vendors to look at support for open standards such as ACME. |
Shall we expect certs to go down to, say 30 days, a few years after 47-day certificates are adopted? | Yes - once this is in-place, with automation more widely-adopted, we expect lifetimes to be reduced further. Nothing is known exactly at this time, but we absolutely predict it will happen. |
Does Sectigo offer a solution which leverages automation standards? | Yes, Sectigo Certificate Manager (SCM) provides customers with a strong foundation of digital trust and integrates with the ACME protocol, as well as other popular automation protocols to enable an accurate and reliable approach to the lifecycle management of short-life certificates. |
It’s hardly surprising that the topic of automation came up so frequently in these questions. With shorter certificate lifespans, the need for automation has never been greater.
Now is the time to look for CA agnostic Certificate Lifecycle Management (CLM) solutions. These solutions help with the automated discovery of digital certificates across vast enterprise environments, regardless of the issuing Certificate Authority, notifying you of impending expirations, and automatically provisioning and installing renewal and replacement certificates. In doing so, they help avoid outages and breaches due to the incorrect use or renewal of digital certificates.
Looking for more information about how automation will enable enterprises retain digital trust against the backdrop of growing numbers of short-life certificates? Read our whitepaper here.