Facing the complexities of Certificate Authority (CA) errors and breaches, savvy organizations are turning to self-signed certificates for communication between internal devices. Traditionally, organizations have leaned on CA-signed certificates for all communications. Yet, the challenge of tracking and updating internal certificates during CA incidents makes managing them a cumbersome task.
This shift in strategy aims to minimize an organization’s threat landscape. By adopting self-signed certificates for internal system communications and network access authentication, organizations attempt to simplify processes. However, this solution comes with its own set of risks. While self-signed certificates seem beneficial, they can open doors to vulnerabilities, potentially exploited by cybercriminals, turning a strategic move into a critical security lapse.
What is a self-signed certificate?
A self-signed certificate is a digital certificate authenticated by the issuer's own private key. Lacking endorsement from a recognized certificate authority (CA), these certificates are typically not trusted by default on many systems, which can result in warnings or errors on public websites.
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.
The use of self-signed certificates, primarily in internal contexts with minimal governance, can present significant challenges for security teams. The primary issue lies in the often limited oversight concerning the quantity, installation locations, ownership, and private key storage of these certificates. This lack of visibility heightens the risk of security breaches. Moreover, the process of addressing these vulnerabilities is further complicated by a crucial limitation: unlike certificates issued by publicly trusted Certificate Authorities (CAs), self-signed certificates lack the capability for revocation, adding an additional layer of complexity to their management.
Wondering how you should manage self-signed certificates in your enterprise? Below are the pros, cons, and alternatives.
Advantages of self-signed certificates
The most tangible benefits of self-signed certificates 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.
Here is a breakdown of common advantages of using self-signed certificates:
- Cost-Effective Solution: The creation and implementation of self-signed certificates incur no expenses, offering a budget-friendly alternative to certificates issued by Certificate Authorities (CAs).
- User-Friendly and Quick Deployment: The process of generating and implementing self-signed certificates is straightforward and swift, rendering them a practical choice for temporary setups or localized systems.
- Unlimited Certificate Creation: There is no cap on the number of self-signed certificates that developers and system administrators can produce. This autonomy eliminates the need for reliance on external teams for the creation of these certificates.
- Ideal for Internal Applications: Owing to the absence of validation by external Certificate Authorities, self-signed certificates are particularly well-suited for use in internal networks, private infrastructures, and testing environments. In these scenarios, the primary concern is encryption, with trust validation being a secondary consideration.
Risks, Challenges and Key Points to Consider with 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.
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.
Other common limitations and considerations for self-signed certificates include:
- Lacking Trust Validation: A primary limitation of self-signed certificates is their lack of external trust validation. Being unendorsed by a recognized Certificate Authority (CA), they often trigger warning alerts in web browsers and other client applications, signaling users to proceed with caution.
- Increased Security Risks: In the event of a compromise, self-signed certificates can become significant security liabilities. Attackers may exploit these certificates to impersonate the entities they represent, leading to potential security breaches.
- Necessity for Manual Trust Configuration: For self-signed certificates to be accepted, users must undertake the process of manually adding them to their trust stores. This procedure demands a certain level of technical acumen and can be particularly challenging for users without technical expertise, often being seen as inconvenient and complex.
- Lack of support and warranty: Certificate authorities that issue public certificates provide a range of services including support, specialized knowledge, and tools for managing their certificates. However, with self-signed certificates, which are created internally, such external support and resources are not available. Managing these certificates requires dedicated human and financial investments to maintain effective control and oversight.
What is the duration of validity for self-signed certificates?
One of the key limitations of self-signed certificates is often mistaken for a benefit: self-signed certificates, regardless of their type (TLS/SSL, S/MIME, document signing, or code signing), 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. Opting for an extended validity period can lead to challenges in remembering the certificate's existence and its expiry date, increasing the risk of overlooking it.
In contrast, certificates that are publicly trusted and used for TLS/SSL purposes are limited in their duration of validity. Since 2020, such certificates cannot have a validity period longer than 13 months, and Google is proposing the mandate of 90 day certificates. Previously, until 2015, they could be valid for up to five years, but this duration has been progressively shortened to just one year, a change affecting both Extended Validation (EV) and Organization Validation (OV) TLS/SSL certificates.
What are the differences between self-signed and other certificate types?
Certificates vary based on the levels of trust they offer. There are two main types: publicly and privately trusted certificates, and they differ in how they establish trust.
Privately Trusted Certificates, which include self-signed certificates, are typically self-signed or created internally within an organization or for use in a private network. Since they're not validated by external CAs, these certificates require users to manually add them to their system's trust store for recognition and trust establishment.
Publicly Trusted Certificates, issued by trusted Certificate Authorities (CAs) like Let's Encrypt, DigiCert, or Sectigo, undergo thorough validation to confirm the identity and ownership of a domain. These certificates are automatically trusted by web browsers and client applications, avoiding any warning messages to users.
Organizations massively underestimate active certificates
Many organizations often miscalculate the actual count of active certificates operating in their systems. For instance, a prominent retail corporation initially thought it had around 5,000 active certificates, only to discover the real number was a staggering 20,000! What's even more concerning is that over 5,000 of these certificates were essentially 'orphaned' – lacking designated owners and clear understanding regarding their functions, permissions, and responsible parties. This kind of oversight tends to be a prevalent issue in environments where self-signed certificates are frequently used.
Combine the inherent weaknesses of self-signed certificates with the common operational difficulties that many organizations encounter, such as expired or improperly configured certificates, and it becomes clear how these vulnerabilities can be readily exploited by attackers. Implementing a robust machine identity management approach is crucial. This strategy should focus on monitoring and detecting certificates, pinpointing unauthorized certificates in operation, and facilitating prompt corrective actions. To further improve security, set a standard baseline and automate the acquisition of new certificates to replace any that fall short of the organization's established policy guidelines.
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, 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.
Recall the 2014 Heartbleed vulnerability? This security lapse highlighted the extent to which organizations rely on keys and certificates without question, and how swiftly and effortlessly cybercriminals can take advantage of a vulnerability related to trust. Remarkably, even three years after its initial revelation, hundreds of thousands of services remained susceptible to the Heartbleed bug.
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
Understanding self-signed certificates is crucial for any organization keen on maintaining robust cybersecurity. As we have explored, these certificates, while offering benefits like cost-effectiveness and ease of generation, also come with significant drawbacks, particularly in terms of trust validation and security risks. Navigating these waters requires a careful approach, balancing the advantages against potential vulnerabilities.
For organizations using self-signed certificates, it's essential to have robust oversight and control. Venafi TLS Protect offers a comprehensive solution to these challenges. It provides unparalleled visibility into your certificate inventory, helps manage and secure your self-signed certificates, and ensures they comply with your security policies. With features like automated discovery and renewal of certificates, Venafi TLS Protect reduces the risks associated with expired or untracked certificates. It also aids in establishing a standardized security posture across all your digital assets. By leveraging Venafi TLS Protect, companies can enhance their security infrastructure, making the management of self-signed certificates both efficient and secure.
(This post has been updated. It was originally published on July 8, 2021.)