Learn Why Self-Signed Certificates Are Evil And Alternatives That Are Good
Self-signed X.509 digital certificates are often used inside enterprises of all sizes on devices and application servers which use HTTPS. Its often so common place in some enterprises that its easy to forget self-signed certificates are evil. Maybe not evil in a deliberate sense, but certainly in an effective manner. Self-signed certificates often lurk in an enterprise and are neglected until used to compromise security which results in serious breaches and damages.
Before we discuss why lets do some level setting and define what a self-signed certificate is.
What Is a Self-Signed Certificate?
A self-signed certificate is a X.509 certificate signed by the same authority as the subject of the certificate. That is the certificate subject is the same as the certificate issuer. Non self-signed certificates are signed and issued by a trusted Certificate Authority (CA) which typically involves a vetting process and issuance process to ensure the certificate is being legitimately requested by an authorized user. Self-signed certificates in contrast, can be created by anyone and can represent any subject entity.
Self-signed certificates can be created using the OpenSSL command line interface (CLI) available for most Linux (Red Hat Enterprise Linux (RHEL), Ubuntu, CentOS, etc), MacOS, and Windows platforms.
What Are Certificates Used For?
Certificates are most commonly consumed by web browsers and other client applications which use HTTPS. The HTTPS protocol uses Transportation Layer Security (TLS), formerly known as SSL, to encrypt the data being sent over a network. An X.509 digital certificate is required on the HTTPS server to validate the identity and create the encryption keys for the session.
Certificates can be used for many other purposes, but the focus of this discussion is on HTTPS/TLS.
The Evils of Self-Signed Certificates
The purpose of a X.509 digital certificate is to represent a validated subject identity. This can be a computer, person, or most any arbitrary entity type. The value of a certificate is only as valuable as the trust of the issuer. When a Certificate Authority (CA) creates a certificate it is typically done using some kind of authentication and vetting process. This might be validating an Active Directory user or computer for an enterprise certificate or some kind of vetting process employed by commercial public CAs.
When you use a self-signed certificate for TLS you have little actual protection. It allows TLS to work but it bypasses most of the protection offered by TLS in the first place. Its like building a castle, outfitting it with Kevlar walls, automatic machine guns, and blast proof doors with an lock made from a sheet of paper.
Let’s explore some scenarios that illustrate the dangers of self-signed certificates.
Evil Scenario #1
Let’s say you have an internal enterprise application which provides a web over HTTPS/TLS interface. If you use a self-signed certificate for this application server you are exposing all that confidential data to potential unauthorized disclosure and compromise. Someone on your network could create their own proxy server with their own self-signed certificate and then intercept and view all the data as it flows to the actual application server.
This can occur because the browser communicating with the application server will not be able to verify the certificate. The browser will present the user with a stern warning saying the site is unsafe. However, it says the same thing when the actual application server responds with its own self-signed certificate. Users have no easy means of telling if the actual application server is responding or if they are talking to the interceptor proxy.
Evil Scenario #2
Building on the previous scenario, imagine if the intruder proxy not only views all the data, but also subtly changes the data. If the application server is providing status on say the temperatures of a fab machine or a nuclear reactor. The proxy could change the results in the data being returned to the user to provide a false view. This could mask a coordinated attack on those devices which could result in the destruction of millions of dollars of equipment and, more tragically, the lose of life.
Evil Scenario #3
If you are using self-signed certificates on even a few servers you will likely be telling your users that if the browser says a site is unsafe due to a self-signed certificate, that they should click the right button to bypass the warning and proceed. Even experienced IT staff will eventually become use to this that they will bypass the warning every time.
So now imagine a bad actor who installs multiple proxies across your network. Suddenly it’s not just one compromised application server but all application servers with self-signed certificates.
Congratulations you have now trained your users to bypass a critical component of your enterprise security.
Evil Scenario #4
It gets worse. Maybe you have your “most valuable” application servers configured with CA issued certificates and only use self-signed certificates on “low risk” servers used for testing or making coffee. What if some of the intercepted data from the self-signed application servers can be used to compromise user or application accounts on the “most valuable” application servers? The intercepted data could be usernames and passwords or could be related data that a hacker could use to guess passwords or execute a phishing attack to trick users into compromising their accounts.
Think your test servers are low risk and self-signed certificates are perfect? Ask yourself how many of your users use the same username and password everywhere? Most likely the number is fairly high.
Once you have leaks in your dam it will quickly crumble under attack from even a modestly skilled intruder.
Why Do People Create Self-Signed Certificates?
Many people create and use self-signed certificates because it’s fast and easy. Running a few OpenSSL commands to create a certificate can be done in a few minutes but requesting a certificate from the enterprise PKI may involve multiple people and take days or weeks to complete.
Many enterprises have a Microsoft ADCS based Public Key Infrastructure (PKI) which integrates well with Windows systems, but requires a long, manual process to create certificates for Linux and MacOS.
Alternatives to Self-Signed Certificates
A solution like CertAccord© Enterprise by Revocent can automate the certificate creation and renewal process on Linux and MacOS by integrating with Microsoft ADCS. The CertAccord agent on Linux and MacOS can actually create certificates from Microsoft ADCS faster than a manual OpenSSL self-signed certificate can be created. Even better, the certificate is fully managed and will be automatically renewed.
When Should Self-Signed Certificates Be Used?
Almost never! The best place for a self-signed certificate is when you are creating a Root Certificate Authority for your enterprise. By its very nature the Root certificate must be self-signed.
Summary
Self-signed certificates are a danger to any sized organization. The longer you go without addressing this the more risk you assume and the harder it is to address over time.
The best course of action is to plan, build, and implement an enterprise Public Key Infrastructure (PKI) with a sound process and consistent best practices.
CertAccord Enterprise by Revocent provides a fast, easy certificate automation platform you can quickly implement in your existing Microsoft ADCS environment to automate certificates on Linux, MacOS, and Windows.
Learn More
To learn more about CertAccord Enterprise, please reach out to us today:
Schedule A Demo