One of the more common TLS faux pas that frequently occurs within many organizations is using the same certificate across several servers. In the worst cases someone will purchase a wildcard certificate, convince themselves that they have discovered the cleverest way to only need to purchase one certificate, and install the wildcard on several hundred servers. But it turns out that this is not such a great idea. My Venafi colleagues Kevin Jacque, Justin Hanson and Benson George have done some great work explaining why the certificate sharing anti-pattern is dangerous and ways that you can measure the value of eradicating this practice in your organization. The following is an excerpt from that project.
Not only does certificate sharing create security issues—like the no-longer-so-private-key—it often backfires spectacularly when the shared certificate expires, and hundreds of systems experience an outage—all at the exact same second. This worst-case example with wildcard certificates is fortunately rather rare. However, there is another TLS certificate-sharing scenario that happens much more frequently. So frequently in fact, odds are good that your organization is doing it today. In this scenario, teams will issue and install the same certificate on multiple servers, usually because those servers are part of the “same cluster”.
Sharing a TLS certificate across multiple servers for an application is not only a bad security practice but causes several other issues that make managing these certificates difficult at scale. Below is a list of some of the potential problems this can cause for an organization.
- Security Concerns: First and foremost, sharing a single certificate across multiple servers increases the potential attack surface within an organization. When a certificate is copied, its private key must also be copied. If any one of those servers were to be compromised, a threat actor could gain access to the shared private key. This key could be used to not only expose sensitive data which the TLS certificate meant to be kept private, but potentially compromising the security of all the servers because it could impersonate all of them.
- Lack of Flexibility: When the same certificate is used for all the servers it limits the ability to manage each server independently. For example, if the certificate needs to be renewed or revoked for one server in the cluster it needs to be done for all of them. This opens the door to unnecessary downtime and other operational issues.
- Challenges at Scale: With modern applications, scaling servers up and down to address load is a common practice. When servers need to be added or removed, a shared certificate would need to be modified to reflect these changes (i.e. Adding a new DNS SAN entry). Once again, this leads to unnecessary operational work, and potential downtime for the other servers.
- Compliance and Audit: Most compliance standards restrict the reuse, copying, or sharing of cryptographic private keys. If your policy is like most, then it follows that an individual private key, and by extension a unique certificate be used for each unique host.
- Troubleshooting and Debugging: When TLS related problems materialize, it becomes cumbersome to isolate the problem to a single server. A certificate is a cryptographic credential used to prove the identity of the holder. This is much like a person’s username and password, or even their passport. When a credential is shared across multiple servers within the organization, it can no longer reliably identify which identity holds it.
While sharing these certificates may seem like a matter of convenience or cost savings, in all actuality this practice introduces significant security, operational, and compliance risks. In the end, certificate sharing is quite operationally inconvenient, and as a result, ends up costing companies more time and money than if they had used a single certificate per server.
Conclusion
At Venafi, we want to help solve the underlying issues that might cause your users to share certificates by making it easy for you to get and deploy TLS certificates. We believe that automation is the future for certificates and the more intelligence you build into the process, the less value a shared certificate offers. Take the first step in identifying shared certificate exposure with our certificate discovery capabilities and start easing the hidden costs of certificate management.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
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.