Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10/15/2020
02:00 PM
Mike Cooper
Mike Cooper
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Overcoming the Challenge of Shorter Certificate Lifespans

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.

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.

Related Content:

Browsers to Enforce Shorter Certificate Life Spans: What Businesses Should Know

State of Endpoint Security: How Enterprises Are Managing Endpoint Security Threats

New on The Edge: RASP 101: Staying Safe With Runtime Application Self-Protection

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."

Mike Cooper is Founder and CEO of Revocent, Inc., and has 30+ years of development, IT, and management experience in small startups to Fortune 500. He has founded more than five technology and consumer companies and was head of IT at another three startups. He spent four ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
mcooper7290
50%
50%
mcooper7290,
User Rank: Apprentice
10/15/2020 | 7:16:58 PM
How short will certificate lifespans come?
My bet is we will see 30 day lifespans within 5 years. Anyone think it will happen sooner or perhaps never?

 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
How to Identify Cobalt Strike on Your Network
Zohar Buber, Security Analyst,  11/18/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: A GONG is as good as a cyber attack.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15246
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.421 and before version 1.0.469, an attacker can read local files on an October CMS server via a specially crafted request. Issue has been patched in Build 469 (v1.0.469) and v...
CVE-2020-15247
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, an authenticated backend user with the cms.manage_pages, cms.manage_layouts, or cms.manage_partials permissions who would normally not be permi...
CVE-2020-15248
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.470, backend users with the default "Publisher" system role have access to create & manage users where they can choose which role the ...
CVE-2020-15249
PUBLISHED: 2020-11-23
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, backend users with access to upload files were permitted to upload SVG files without any sanitization applied to the uploaded files. Since SVG ...
CVE-2020-28927
PUBLISHED: 2020-11-23
There is a Stored XSS in Magicpin v2.1 in the User Registration section. Each time an admin visits the manage user section from the admin panel, the XSS triggers and the attacker can able to steal the cookie according to the crafted payload.