As of September 01, 2020, TLS certificates that are issued on or after that date will have validities that are capped at 398 days (13 months). The move is a culmination of events that were set off by Apple’s announcement in March that it would not permit any certificates issued post-September to possess the usual validity period of 24 months. This would simply mean that Apple’s Safari browser (and Apple devices) would fail to recognize any certificate, however legitimate, that had a validity period of longer than 398 days. Other leading browser vendors (including the likes of Mozilla, Google, and Microsoft) soon followed suit.
While this is undoubtedly an indicator of progress towards a higher bar for cybersecurity and a more secure environment for end users, this also means that parties that purchase and use certificates have to be more diligent with their PKI management practices.
Control Your Certificates Before They Go Rogue!
That said, let’s take a closer look at how this came to be, and how certificate users can adapt to it.
The CA/B Forum
The CA/Browser forum is a group that has been active since 2005, and is a body composed of Certificate Authorities (CAs, for short), and Browser Vendors that permit the use of the certificates issued by CAs. The group is responsible for defining common ground rules regarding the issuance and usage of certificates on browsers and devices, and the associated restrictions surrounding them. One of the key points of discussion for the CA/B forum is the permissible lifespan of TLS certificates.
While TLS certificates started out with 8-year lifespans, the efforts of browser vendors have managed to shrink these lifespans significantly over the years. In 2018, the existing standard validity period of 3 years was slashed, resulting in a 2-year validity across the board, a move that was enforced almost instantly. The CA/B forum convened again in late 2019 to vote upon a motion that would result in a 1 year validity, but CAs voted against this move, deeming it unnecessary.
398-day lifespans: How, and Why.
This February, Apple made the announcement we mentioned earlier: It would enforce a 398-day certificate lifespan across all its devices and browsers, starting September. Soon after their decision hit the news, Mozilla and Google made similar announcements, reinforcing the point that Apple was trying to make: Certificates with shorter lifespans are safer and more conducive to effective cybersecurity strategies.
Why is this so?
A standard certificate’s life cycle begins when it is issued by a Certificate Authority. When the organization that is using that certificate stops using it, they request the CA to revoke it in order to ensure that the discarded certificate cannot be used by malicious actors as a backdoor into their network. However, in practice, several discarded certificates are not revoked in time, or at all. Since a certificate can technically be used for a time period lesser than that of its actual life span and then discarded, they continue to remain valid long after they have been cycled out of use. Since administrators usually do not monitor unused certificates, they could serve as a convenient infiltration tool for bad actors who get their hands on them.
Browser vendors have argued that making these certificates invalid faster (within 13 months of their issuance, in this case), will reduce the possibility of them being misused in the event that they are discarded and not revoked in time. Shorter validities also mean that changing standards and technological updates can be adopted by end users faster, as they will not be stuck using still-valid certificates that were issued years ago.
Adapting to shortened lifespans.
Of the four parties involved in the use of TLS certificates (browser vendors, end users, certificate buyers, Certificate Authorities), the former two will remain relatively unaffected by this shift.
On the other hand, CAs will have to change their processes in order to ensure that every certificate issued after September 1, 2020 will expire 398 days after it is issued. If not, browsers will fail to recognize them from the get-go.
Certificate buyers (parties/individuals that purchase the certificate in order to install them on their websites, servers, or devices), on the other hand, have quite a bit of work to do:
Policy changes: Certificates purchased prior to September can follow the usual life cycle of being renewed after 2 years, but every new certificate purchased must absolutely be renewed every 13 months, failing which their website/device will fail to be recognized as legitimate on the internet. Certificate lifecycles have to be diligently managed to ensure that certificates approaching expiry are renewed on time, and if not, discarded (with a revocation notice sent to the CA immediately).
Here’s some more information on managing certificate lifecycles (and automating them)