Overcoming the Challenge of Shorter Certificate Lifespans

In August 2019, Google introduced CA/Browser (CA/B) Forum Ballot SC22 to reduce Transport Layer Security (TLS) certificate validity periods to one year. After much discussion and thousands of comments — mostly in opposition — the ballot failed and certificate maximum lifetimes remained at two years. Or so we thought. Even though shorter certificates enhance ecosystem security – and the lifespans are steadily getting shorter — the overall consensus at the time was that shorter certificates would put too much burden on overworked IT teams.

As a voluntary group, CA/B lacks the authority to force organizations to unilaterally accept such outcomes. In fact, the real power lies with vendors like Apple and Google. So, at the CA/B Forum meeting this past February, Apple announced that beginning Sept. 1, any new website certificate valid for more than 398 days will not be trusted by the Safari browser and instead will be rejected.

By implementing the policy in Safari — which is used on a billion or so devices and computers around the world — Apple effectively set the standard for the industry. Since then, Google and Mozilla have joined Apple in limiting public TLS certificates to 398 days, also starting Sept. 1.

Like it or not, shorter certificate validity is here to stay. And chances are the various powers that be aren't done yet. In fact, we could be in the middle of a major transition to shorter and shorter certificate life spans, which has significant implications for how IT organizations manage certificates across the enterprise.

Compounding the problem is the dramatic increase in the number of devices and applications that require certificates. Most applications and systems rely on digital certificates for secure connections, making the task of managing certificates from initial request through to renewal that much more difficult.

A Slow Burn
In many ways, IT managers have been lulled into a false sense of complacency. Early on, multiyear certificate lifespans were the norm and certificate volumes were manageable. Windows systems have the ability to automatically create and renew certificates, though this is limited to storing the certificate on the endpoint. Each new certificate still requires manual configuration with an application in many cases. This was somewhat acceptable when certificates were valid for two or more years.

When exceptions like a Linux or Mac system that wasn't part of the Microsoft-based enterprise PKI came up, they were handled on a one-off basis. By default, this led to the creation of manual processes. Such processes were easily justified by saying that the certificates could be easily tracked using a spreadsheet, and since the numbers were small and certificate renewals were years apart, it wasn't worth the effort to get a product to solve the problem when the existing solution was sufficient.

Even when the volume was small, management of X.509 certificates using manual methods was never a good idea. People make mistakes. Certificates get forgotten. Expiration periods were made so long (to avoid forgotten, expired certificates) that the organization exposed itself to potential security breaches. Moreover, organizations tend to underestimate the amount of care and feeding required to manage certificates. A manual issuance process alone can take three to six hours. You have to generate a key pair, create a certificate signing request (CSR), submit it to a certificate authority (CA), wait for a public key infrastructure (PKI) administrator to issue a certificate, download the certificate, configure and update the application using the service, and finally verify it's active. It also helps if you have a solid background in PKI so you don't make mistakes along the way.

Because of the effort and time involved with manual processes when organizations get to about 100 or so X.509 certificates, it's usually time to add a full-time dedicated PKI expert to manage certificates — if such a resource can even be found. Given the ongoing cybersecurity skills shortage, finding the right resource is never a given. When key positions go unfilled, the burden for certificate management gets spread across multiple team members who already have full plates, putting pressure on budgets and creating room for errors and outages. And when certificates need to be renewed, the workload associated with renewal in a spreadsheet-based certificate management system is massive. Given all this, there's little wonder that CA/B members were opposed to shorter certificate lifespans.

Carrot and Stick
If shorter certificate lifespans are the stick, then the move to a fully automated certificate management system (CMS) is the carrot. [Editor's note: The author's company is one of a number that offer CMSs.] When a CMS is used to create a certificate, it has all the data it needs to not only monitor the certificate for expiration but automatically provision a replacement certificate without human intervention. This frees up your infosec team from the tedium of crunching through lengthy spreadsheets so they can accomplish more value-added tasks. It also eliminates an estimated 90% of certificate-related issues.

As a stopgap, some organizations may opt for an inexpensive or open source monitoring and alert system (MAS) to track certificates that fail to meet requirements or are about to expire. They often believe that a MAS will be faster and cheaper to deploy than implementing a CMS. While some CMSs can be incredibly complex, expensive, and time-consuming to install, there are CMS offerings available that can be easily installed and extend the Microsoft-based PKI to encompass certificates that are installed on systems and applications outside the purview of Active Directory, such as Linux or MacOS devices.

Despite the added burden placed on IT staff, shorter certificate lifespans are here and will only continue to get shorter. In the not too distant future, it's possible we'll see certificate lifespans as short as 30 days simply through the actions of external forces. To avoid placing unreasonable burdens on IT as these changes become real, organizations need complete visibility into certificates expiration dates coupled with comprehensive automation across their cryptographic infrastructure. As Gartner analyst David Mahdi writes, now is the time to "invest in the people, process and technology to help tackle certificate management and avoid downtime, and potential brand damage."