As organizations begin to realize that 90-day certificates are destined to become the industry standard, they have a variety of reactions ranging from panic to a false sense of security and even denial. Regardless of which camp you are in, it’s time to start thinking about what it will take your organization to convert your entire public facing TLS Server certificate inventory to 90-day lifespans. That standard for shorter certificate lifespans will be here before we know it, and to put it bluntly, at that point you’ll need to be prepared to automate to survive. You will also likely need to rethink your approach to certificate discovery, especially if you're relying on Certificate Transparency (CT) logs instead of endpoint discovery.
To that end, there have been a lot of opinions about where you should start preparing for shorter certificate lifespans. Creating and maintaining a complete certificate inventory is the most obvious place to start. But that may not be as easy as it would sound. Many large organizations have hundreds of thousands of certificates. And the chances are pretty high that when you really start to dive deep into the discovery process, you’ll uncover certificates (often from unauthorized CAs) that you didn’t know exist.
There has been some noise lately about discovery approaches that rely heavily on Certificate Transparency (CT) logs. Granted CT is an important function in validating the authenticity of certificates. And it certainly has an important role in identifying unsanctioned or even malicious certificates. But it has not been designed as an overall discovery tool. And placing too much emphasis on CT for discovery may raise more issues than value.
Are you ready for a seamless transition to the 90-day TLS/SSL certificate standard?
But before we discuss the challenges of using CT as a primary discovery tool, let’s look at the strengths of CT and its value in managing and protecting TLS certificates in the machine identity lifecycle. A CT log is basically a log of all CAs that issue public certificates—and it’s really helpful if you don’t know about all your CAs. You can use CT logs to see what public certificates have been issued that reference your organization’s domain names.
But if that’s all you have, it's not super helpful. In fact, it's more counterproductive because you’re just given this big mess of data that you may not know what to do with. And it may take forever to reconcile this data with your inventory, especially if you don't exclude things like expired certificates from your query to the CT logs.
So what's really helpful is when you combine discovery sources that are host based—which would include network discovery where you discover what's actually deployed—with what you know from CT logs and CA imports. For example, Venafi TLS Protect uses a CA import function that communicates with the CA to provide a log of everything they’ve issued. And what's valuable about this is that if you know your CAs, then nothing gets missed and you know about everything that's been issued. This is especially important for Private CAs that don’t publish to CT logs. However, there still may be certificates that were issued, but not ever deployed for use or were in use at one time but have since been revoked. That’s where CT is awesome as a discovery supplement, not as an overall basis for certificate discovery.
In other words, once you’ve found everything you can through network machine-based discovery and other methods, you then can look at the delta between what you’ve discovered and what you weren’t able to attribute to being installed in your organization. And if that's a small number, then you may want to go through the list one by one and determine whether it’s because you didn't find it, it was never used or isn't no longer being used. It’s best to get your application teams involved in this part to help with this review process. After all, many hands make light work.
But let’s say your endpoint discovery finds only 20% of what you found on CT logs. Could you tell if there were any gaping holes in how you did your endpoint discovery? If not, then you're not going to spend time going through 80% of the CT logs, it's just too much noise to really make that be an effective exercise.
On the other hand, once you've done all your endpoint discovery and there's only 15% flagged by CT logs, then it's worthwhile to figure out from the remainder what's noise and what's identifying a hole in your endpoint discovery process.
So what this comes down to is that endpoint discovery has to be your key strategy because it tells you what's currently in use and where it's being used. This is why the Venafi strategy is so important because we use all sorts of different methods to build it your inventory. We’ll also discover certificates status to minimize the time you need to reconcile your inventory.
And because Venafi filters out all of the noise for our customers, we’re showing them virtually no false positive because we've confirmed it through our own automated endpoint discovery that they don't have to do any configuration to get those results. Instead, they can focus on certificates that they know are currently in use and could be expiring soon and need to be replaced. So we know what information you need, and we've already presorted that for you. So that what you get is what you need.
And that’s one of the big criteria for 90-day certificates. To successfully automate a shorter lifecycle for your certificates, you need to know certificate properties such who owns it, where it's being used, and more. CT logs will give you none of that. All CT tells you is whether a certificate has been created.
So my recommendation is to opt for a mature discovery process that combines a variety of sources used strategically to deliver a complete inventory with the least possible effort on your side.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
![Summit 2024 Teaser Photo](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F537b500f-ee2a-44ba-82b4-d7be0b23506c%2Fsummit-promo-graphic-2.jpg&w=3840&q=75&dpl=dpl_9nMnPWFgUR3MNGqVKD9tfneGCtKt)
Machine Identity Security Summit 2024
Help us forge a new era of cybersecurity
☕ We're spilling all the machine identiTEA Oct. 1-3, but these insights are too valuable to just toss in the harbor! Browse the agenda and register now.