I enjoy a good science fiction movie so gave Voyagers a try recently. If this were a movie review, I’d give it two thumbs down for poor execution, but the description was interesting enough, "An expedition to colonize a distant planet descends into chaos as the young astronauts explore their most primitive natures in this sci-fi thriller." Think George Orwell’s Animal Farm, but with teenagers on a spaceship rather than pigs on a farm.
At the start of the movie, all the teenage astronauts are basically equal, just like in Animal Farm where “all animals are equal.” But in the movie, as in the book, that quickly changed. For the purposes of this blog, I will use “equal” with quotes to note where at first glance, a TLS certificate might seem the same as any other but, in reality, it’s not that equal at all.
In the world of machine identities, there are those like TLS certificates that, at first glance, seem like they’re all equal. All TLS certificates do play a critical role in securing and encrypting communications between machines (e.g., like a client and a server). However, in practice, there are actually subtle differences—in the TLS certificates themselves, where they’re used, and who is using them. Considering these differences, you’ll need to carefully choose which certificates you use in your organization and how those certificates should fit into your machine identity management strategy. I’ll explore a few of these areas that come up frequently in conversation with Venafi customers.
What type of TLS certificates are you using?
It’s important that you know which different types of TLS certificates that are suitable for different use cases in your organization. At a high level, there are public and private TLS certificates. Public TLS certificates are issued by a trusted certificate authority (CA) for use on things like public facing websites. Private TLS certificates are typically used on internal networks and are issued either by a trusted CA or by an internal PKI within your organization, like Venafi Zero Touch PKI. You could make a case that public TLS certificates should be more “equal” than private ones given they’re exposed to the internet. However, as we’ve discussed in recent blog articles, if you’re adopting a Zero Trust model (which you hopefully are), it’s important to secure every connection point which means both public and private TLS certificates need to be included in your machine identity management strategy.
When you buy a public TLS certificate from a trusted CA, there are different options. There’s lots of great information about Domain Validated (DV), Organization Validated (OV) and Extended Validated (EV) from our many Certificate Authority technology partners if you want to learn more about the differences. In a nutshell, each of these types of TLS certificates has different layers of validation that are designed to gauge their levels of trust.
One other option that I want to highlight here is a wildcard certificate. A wildcard certificate is a public certificate that can be used on multiple subdomains. For example, if I had a wildcard certificate for venafi.com then I could cover:
Where are you using the TLS certificate?
As mentioned earlier, TLS certificates play a critical role in secure and encrypted communications between machines. Since organizations today have more machines in more places than ever before, there are more use cases for TLS certificates. In this growing landscape of machine identities, one way to determine if one certificate is more “equal” than another is to identity where the certificate is being used. A print server and a load balancer should both have a certificate but if you are looking to prioritize that as part of your machine identity management program, which one should be an initial wave of automating certificate renewals? The certificate on the load balancer probably plays a more important role to the organization and for that reason probably should be prioritized higher.
What is the volume and velocity of your certificates?
While some TLS certificates can stay on a website, server, device, or other machine for a long period of time (398 days for public TLS certificates from trusted CAs), other TLS certificates have much shorter lifespans. Virtual machines, cloud instances, containers and microservices that need a TLS certificate can be spun up in seconds. They can also be retired just as quickly. When issuing TLS certificates becomes part of an automated build process, a certificate might be requested but then retired after several minutes, hours, days, or weeks when there’s another build.
That brings up an interesting point. Are TLS certificates that are needed quickly and have a shorter lifespan less “equal” than other TLS certificates and therefore don’t need to be included in a machine identity management program? We know from working with Venafi customers that one of their biggest TLS certificate challenges is certificates that expire and cause an outage. But that may not be as much of a factor for certificates with short lifespans. However, there are many other reasons that even a short-lived certificate needs to be part of a machine identity management program. It's important that all certificates are compliant with security and audit policies. And without guidance, developers might take shortcuts that increase security risks like:
- Creating their own certificate authority (CA) to issue certificates
- Using CAs outside of policy
- Using improperly signed certificates
- Not following practices for secure issuance, configuration, or installation
You need to manage all TLS certificates, even if they are not created equal
While all TLS certificates perform similar functions, it's true that some TLS certificates are more "equal" than others. That said, there are reasons to include all your TLS certificates in your machine identity management program, even if factors such as how or why you manage them may vary. With the Trust Protection Platform, Venafi helps hundreds of leading organizations successfully manage TLS certificates and other machine identities in a whole spectrum of diverse environments.