Dangers of Using Self-Signed Certificates
Reading time: 8 minutes
SSL certificates are an integral part of today's internet, allowing applications and services such as banking and other financial resources that require maximum security to be accessible from the comfort of one's home.
SSL certificates are critical to ensure that you're connecting to an actual website—and not falling victim to a DNS poison attack or man-in-the-middle-attack that leads you to a phishing website.
SSL certificates have also come a long way since they were first introduced. At first, they were only considered important for large organizations and financial services. And with only a handful of issuing authorities, SSL certificates were out of reach for many smaller organizations.
Over time, however, certificates grew more and more necessary for smaller organizations as well, to protect team members working from home. The general adoption of SSL certificates increased, with the EOL of Windows XP and support for technologies like SNI becoming available in all operating systems.
Newer vendors like LetsEncrypt, backed by the EFF, that have made SSL certificates available for everyone for free (and with easy to use software like CertBot and Google search prioritizing SSL secured websites) have further boosted the popularity of SSL adoption.
At the same time, self-signed certificates have not completely disappeared. Self-signed certificates are often used in internal deployments, temporary build environments and in legacy environments where certificates of certain strength (which are often insecure) are needed to keep legacy applications running.
All of the above come with inherent risks. Using them is no different than running expired SSL certificates, which are flagged as insecure by all modern web browsers.
Today we'll dig into what are self-signed certificates, the dangers of using them for your organization, and ultimately how to quickly identify each one of them.
- What is a self-signed certificate?
- Dangers of using self-signed certificates
- How can you prevent such risks, and detect them in your infrastructure?
- Summary
What is a self-signed certificate?
A self-signed certificate is simply an SSL certificate that is signed and generated by an individual (like you). This type of SSL certificate is valid only on devices where it is installed into the SSL certificate store.
If a visitor accessing your website or web application does not have this certificate installed on their device, an SSL warning would pop up in your web application or website's browser.
While self-signed SSL certificates were the norm back when commercially available SSL certificates were expensive and available only to larger corporations, we still see them used in organizations' intranets and development environments. This is due to the relative ease of signing and deploying self-signed SSL certificates.
This is especially true in environments which are firewalled from the public internet, and for legacy resources and services which need certificates signed with weaker ciphers (for example RC4, 3DES, and others).
While self-signed certificates do have their advantages, they're not without their dangers. They're inherently risky for simply being self-signed.
All commonly used web browsers display errors when websites or web applications with self-signed certificates are accessed, when the end user does not have the certificate installed on their device. Take a look at the following examples.
On Chrome:
On Edge:
On Firefox:
On Internet Explorer:
Dangers of using self-signed certificates
The common use of SSL certificates, bolstered by their ease of re-issue, emphasizes the degree of inherent risk they involve.
Root certificates can be leaked
Your SSL certificate is only as secure as its root certificate—any leak of which can render your SSL certificate compromised. Large SSL certificate organizations like Comodo and Thawte know this, with substantial teams and policies in place to protect and secure their root certificates.
Maintaining such security can be tricky on a smaller scale, however. If your SSL certificate is used on multiple web applications or websites and its root certificate is stolen, this can lead to the attacker generating multiple SSL certificates—which would be trusted by all the devices you have the certificate installed on.
This also opens up a large attack vector if the attacker is targeting an organization which has all of its internal and private websites secured by a self-signed certificate.
Certificate warnings can be ignored
From a human perspective, under intranets or development environments, team members are often instructed to accept SSL security warnings and proceed. While this does solve the issue of not having to deploy a valid SSL certificate for each intranet website or application test deployment, and allows the team member to continue accessing the deployment, it also builds a habit of accepting certificate warnings without paying much attention.
In turn, this casual negligence can be used to trick the team member into accepting an SSL certificate warning on a phishing website or something similar, causing a security compromise of their organization.
Brand reputation damage
Whether it’s all the security warnings associated with self-signed SSLs, or the consequences of a potential MiM attack, using self-signed certificates can cause severe damage to your online reputation and lead to loss of your customers’ trust. This will ultimately cause financial loss as users will not feel safe making an online purchase from a web-based application that is showing browser security warnings.
How can you prevent such risks, and detect them in your infrastructure?
Preventing the usage of self-signed SSL certificates is relatively easy when deploying certificates for modern web applications and websites. In most cases they can also be free of charge, with the likes of LetsEncrypt and CloudFlare providing free certificates for all. In cases where organizations prefer to have paid SSL certificates, there remain many options including Thawte, Comodo, GlobalSign and others.
Remember that larger organizations can have multiple teams, internal websites and web applications, many of which are simply forgotten over time. Tracing such websites and web applications, and then setting up valid SSL certificates for all of them, can be a difficult task, which often leads to them being overlooked. This can make your entire organization vulnerable, with an attack vector just waiting to be used.
Fortunately, tracing and listing out these domains and services is easy with SurfaceBrowser™, as you can see in the following video:
In order to perform this quick SSL tracing, you'll need to log in to your SecurityTrails™ account at https://securitytrails.com/, and then click at the SurfaceBrowser™ icon at the top left corner. Then, enter your organization’s domain, as you see below:
On the sidebar, head over to the SSL tab:
Here, you see all the SSL certificates issued to General Electric (GE) as well as the associated information for each certificate, such as:
- The domain to which the certificate has been assigned
- The organization to which the certificate has been issued
- The issuer of the certificate
- When the certificate was created
- When the certificate expires
You also have the option to filter and find valid certificates, expired certificates and all certificates, as shown in the following screenshot:
For example, if we wish to list only the expired certificates, we can select the "Expired certificates" option under the the "Filter by:" dropdown.
Once filtered, we're able to see all the expired certificates, the domains they're associated with, the organization the certificate was issued to, the certificate issuer, when the certificate was created and finally the date when the certificate expired.
## Detecting self-signed certificates with ASI
As you can see, SurfaceBrowser™ allows you to get a complete picture of all your SSL certificates, including the issuer of each SSL.
However, our attack surface management all-in-one tool — Attack Surface Intelligence, can also help by specifically detecting all self-signed certificates inside your organization:
As seen above, from the 'Risks' tab you can find all the SSL intel you need, such as Hostname, IPs, Subject, Issuer, and Not before and Not after dates:
This data makes your job of finding self-signed certificates easier and done within seconds, without any manual work involved from your side.
Summary
While using self-signed SSL certificates is often considered the norm when accessing internal websites and web applications, ever-increasing threats to root certificate security and human factors such as social engineering and phishing have made using a valid and non-self-signed certificate a critical security standard.
Using Attack Surface Intelligence makes it possible to filter your organization's issued SSL certificates, letting you know if the certificate is a self-signed one, as well the domain it’s issued to. This feature-rich intelligence tool makes finding and securing forgotten and legacy web applications easier than ever.
