Traditionally, organizations have used certificates signed by Certificate Authorities (CAs) to secure both external and internal communications. But internal certificates can be more difficult to find and replace, making it more challenging for organizations to manage internal certificates in the event of a CA error, security breach, or attack on a CA.
As a result, organizations are looking for ways to reduce their threat landscape. One strategy is to use self-signed certificates to secure communications between internal systems as well as to authenticate devices and users to the internal network. The benefits of this strategy, however, do not outweigh the risks. In fact, the aspects of this strategy that appear advantageous can be exploited by bad actors and turned into a gaping vulnerability.
What is a self-signed certificate?
A self-signed certificate is a digital certificate signed by its own private key, rather than by a publicly trusted third-party Certificate Authority (CA). Since the certificate is not issued by a recognized CA, it is not inherently trusted by default on most systems, leading to a warning or error message when encountered on a public website. But self-signed certificates are still quite common. They are now primarily used for internal purposes, such as testing, development environments, or private networks, where the need for third-party validation is minimal.
However, because they are used internally with little or no governance, self-signed certificates can quickly become the bane of security teams, who often lack visibility over how many they have, where they are installed, who owns them, and how the private key is stored. This makes the use of self-signed certificates vulnerable to compromise. And remediate is complicated by the fact that, unlike publicly trusted CA-issued certificates, self-signed certificates cannot be revoked.
Wondering how you should manage self-signed certificates in your enterprise? Here is a brief list of the pluses and minuses:
Advantages of self-signed certificates
- Cost-effective: Self-signed certificates are free to generate and use. There are no fees associated with obtaining a certificate from a CA.
- Easy to use: Self-signed certificates can be generated and deployed rapidly, making them ideal for temporary or local environments.
- Unlimited generation: Developers and application owners can create as many certificates as they need without limitation or dependence on other teams for certificate generation.
- Internal use: Since self-signed certificates are not validated by third-party CAs, they are suitable for internal systems, private networks and test environments, where the focus is on encryption rather than trust validation.
Limitations and considerations
- Lack of trust validation: The major drawback of self-signed certificates is the absence of trust validation. Since they are not issued by a recognized CA, web browsers and other client applications will display warning messages, urging caution to users.
- Risk of compromise. Compromised self-signed certificates can pose many security challenges, since attackers can spoof the identity of the victim.
- Manual trust establishment: Users must manually verify and trust self-signed certificates by adding them to their trust stores. This process requires technical knowledge and can be cumbersome, especially for non-technical users.
What are the differences between self-signed and other certificate types?
Certificates can be classified based on the trust levels they provide. Publicly and privately trusted certificates differ in the way they establish trust with users. Publicly Trusted Certificates are signed by trusted CAs, such as Let's Encrypt, DigiCert or Sectigo. They undergo rigorous validation processes to ensure the identity and ownership of the domain. Publicly trusted certificates are recognized and trusted by web browsers and client applications without displaying warning messages. On the other hand, privately trusted certificates are self-signed or internally generated certificates used within an organization or private network. They are not validated by recognized CAs and require manual trust establishment by adding the certificate to the trust store of the systems that interact with them.
Are there benefits to using self-signed certificates?
As stated above, the most tangible benefits of this strategy are saving money and reducing administrative efforts. Additionally, self-signed certificates are a valid alternative for securing internal communications or testing environments.
If properly secured, self-signed certificates can actually reduce the risk profile of using CA-issued certificates for internal communications. However, if you do not have the ability to continuously monitor and protect self-signed certificates, cyber-criminals can conduct man-in-the-middle (MitM) attacks to impersonate banking, e-commerce, and social media websites.
SSL/TLS Certificates and Their Prevalence on the Dark Web
The major risks of self-signed certificates
When compared with certificates signed by CAs, self-signed certificates are often viewed as less trustworthy because they contain both the public and private keys in the same entity. With signed certificates, a trusted Certificate Authority must verify the certificate applicant's domain ownership and identity information, whereas anyone can generate a self-signed certificate without having to submit through this means of authentication.
One of the key limitations of self-signed certificates is often mistaken for a benefit: self-signed certificates cannot be revoked, and they never expire. This makes a compromised certificate difficult to identify, which has several security challenges. CAs can revoke a certificate if they discover it has been compromised, but organizations must go through the process of replacing or rotating the certificate. This “set it and forget it” mentality around certificates, along with the inability to rapidly revoke a compromised private key associated with a self-signed certificate, can open the door to malicious attackers. As we have discovered, shorter certificate validity periods are a good thing.
It’s also important to be aware of how in-house developers are using self-signed certificates. Rather than purchasing CA certificates, individuals tend to rely on OpenSSL, an open-source implementation of SSL, to create the certificates they need. This requires developers to request and configure each certificate independently, which is an enormous effort that essentially offsets the administrative responsibilities of a CA.
Organizations massively underestimate active certificates
In addition, most organizations underestimate the number of active certificates in use on their systems. For example, one major retail organization estimated it had 5,000 active certificates, but it really had 20,000! Even more alarming, more than 5,000 certificates had no owners, and no one knew what they did, what they allowed, and who was responsible for them. This lack of insight is common when organizations use self-signed certificates.
Couple these self-signed certificate vulnerabilities with the operational challenges most organizations face with expiring and misconfigured certificates, and you can see how attackers can easily exploit this vulnerability. A machine identity management strategy is vital to detect and monitor certificates, identify rogue certificates in use, and quickly remediate. For added protection, establish a baseline, and automatically acquire new certificates to replace those that do not comply with the policies they have established.
Machine identity management solutions, such as TLS Protect by Venafi, eliminates the headache and human error from using CA-signed certificates with automation and full certificate visibility. Discover exactly how many keys and certificates you have across environments and automate replacement.
Cyber attacks that have exploited self-signed certificates
Several attacks have successfully exploited self-signed certificates. For example, thousands of malware samples
For example, one variant of the Dyre banking Trojan uses a self-signed certificate to communicate with its command-and-control (C&C) server over ports 443 and 4443. This certificate makes the Dyre variant's exfiltration traffic look like regular browser traffic, thereby rendering the malware more difficult to detect and analyze.
Dyre isn't the only malware to use self-signed certificates. Another highly sophisticated banking Trojan known as Shifu replicates Dyre's secure communications model with its own C&C infrastructure. By contrast, a Mac-based threat called Flashback uses self-signed certificates to trick users into installing the Trojan onto their machines.
Remember the Heartbleed vulnerability from back in 2014? That flaw showed exactly how organizations blindly trust keys and certificates and how quickly and easily cyber-criminals can exploit a trust-related vulnerability. Astoundingly, hundreds of thousands of services were still vulnerable to Heartbleed three years after the bug's disclosure.
Alternatives to self-signed certificates
Self-signed certificates are ideal for non-public-facing systems, where encryption is the primary concern rather than trust validation. They are commonly used in development, testing, or local environments. However, alternative solutions can offer improved security, trust validation, and streamlined certificate management.
- Self-service certificates: Empowering users with secure certificates Self-service certificates enable organizations to simplify the generation of publicly trusted certificates by delegating the responsibility of certificate creation and management to individual teams or users. Self-services certificate solutions often provide user-friendly interfaces and workflows that allow teams or users to generate their own certificates easily. This reduces the burden on central IT or security teams and fosters agility within the organization. This helps in enforcing security policies, monitoring certificate usage, and maintaining compliance.
- cert-manager: Kubernetes-native certificate management cert-manager is a popular open-source certificate management solution specifically designed for Kubernetes clusters. cert-manager integrates with trusted CAs, enabling the issuance of certificates from those CAs for use within Kubernetes deployments. This ensures that the certificates obtained through cert-manager are trusted by web browsers and client applications. Plus, cert-manager is ideal for developers because it is tightly integrated with Kubernetes, providing seamless certificate management within the Kubernetes ecosystem. And with Venafi's TLS Protect for Kubernetes, security teams can also gain cluster-wide visibility and policy enforcement.
Conclusion
All certificates, especially self-signed certificates, need to be secured and protected. Most organizations do not know exactly how many certificates are in use within their infrastructures, where they are located, or how they are used—let alone how many of these unknown assets are self-signed or CA-signed. They must not only know which systems use self-signed certificates but also replace these certificates on a regular basis.
(This post has been updated. It was originally published on July 8, 2021.)
Get a 30 Day Free Trial of TLS Protect Cloud, Foolproof Certificate Management.
Related blogs
