The growth of digital threats has made our need for security more pervasive. Where possible, we try to use active schemes. However, private key infrastructure and certificates serve a powerful purpose and will continue to do so for the foreseeable future. As threats grow, we as systems administrators need to improve the way that we protect against them. This article starts a series on PKI and related certificates with a call to action: stop using self-signed certificates.
[citationic]
The Definition of “Self-Signed Certificate”
Before explaining the problem with self-signed certificates, we need to disambiguate the term a bit. Sometimes, people refer to certificates signed by an internal certificate authority as “self-signed”. In that sense, instead of using an external authority, the organization signs its own certificates. Hence, they refer to them as “self-signed”. We should probably discourage people from using that term. Either way, that sort of certificate has perfectly valid uses, so use them wherever appropriate. In this article, and across Project Runspace, we only use the term “self-signed certificate” to refer to certificates where the “Issued By” and “Issued To” sections refer to the same entity.
Why We Use(d) Self-Signed Certificates
We have one permanently valid reason for self-signed certificates: a root certificate authority cannot exist any other way. We will use that knowledge in a later article.
By most any standard, dealing with certificates is obnoxious. For them to have any value, they expire, so they need routine maintenance. Despite relatively widespread usage, few administrators have in-depth knowledge of how certificates work. Gaining the knowledge means yet another technology to learn when we all have so many high priority things taking up our time. So, when a tool offers a self-signed certificate to make something easier, we go with it.
The problem with self-signed certificates? They don’t do anything. In other words, only superficial differences exist between self-signed certificates and none at all. Worse, they can give a false illusion of security.
The Primary Value of Certificates: Authentication
Almost universally, people refer to the certificates of a public key infrastructure (PKI) as “SSL certificates”. SSL stands for “secure sockets layer” and refers to a protocol used for encrypted communications. However, “used” appears here as a past tense. After multiple revisions culminating in 3.0, SSL was abandoned. The security vulnerabilities in that final release have no fixes. Instead, the industry replaced the protocol with the newer TLS (transport layer security). We still use the term “SSL certificate” for no real reason other than because that designation took hold and everyone recognizes it. These certificates, however, do not belong to SSL. A more apt name might be “PKI certificate”, if we can ever make that popular.
As long as everyone can understand the real purpose of a certificate, then the name makes no difference. However, the presence of “SSL” connotes that certificates mostly mean encryption. That misunderstanding lies at the heart of most improper uses of certificates. Above encryption, a certificate establishes identity. Consider paper certificates. We don’t use them to encrypt things, we use them to identify things, usually to signify members of something. Digital certificates have the same core purpose.
Self-Signed Certificates Do Not Confirm Identity
Recall from the introduction that a self-signed certificate has an identical value for the “Issued by” and “Issued to” attributes. It has the same meaning as a paper certificate on which I attest, “I am Eric Siron, certified by Eric Siron.” Perhaps you trust me to make that statement. However, how do you know who wrote it? Contrast that with a government-issued certificate, such as a driver’s license. Consider the difference in the level of trust and difficulty of forgery for the document itself. As you will see in a later article, anyone can create a self-signed certificate with almost no effort. Forging a functional certificate from a trusted authority needs substantially more effort.
Yes, TLS can use the keys in a self-signed certificate for the same levels of encryption that it would use for an authority-signed certificate. However, you have the same problem: how do you know that the certificate used for encryption was issued to the identity that appears on the certificate? Unless it came from a separate authority that you trust and can use to validate the certificate, then you cannot.
The first problem with self-signed certificates: when used in signed or encrypted transmissions, you can only have any certainty that the data was not altered in transit. You have no way to know who signed or encrypted the information. All other verifying points, such as IP addresses, require even less effort to falsify than the name on a self-signed certificate.
Self-Signed Certificates Have Lost Convenience
We still have the obnoxiousness factor of certificates, and will likely never rid ourselves of it entirely. For a time, self-signed certificates took so much less effort than authority-signed certificates that many of us took the easier path. Things have since changed.
First, many tools now recognize self-signed certificates and reject them or otherwise make them difficult to use. Browsers know not to trust them. Software like Windows Admin Center will generate a certificate for you, but it expires after only 30 days.
Second, acquiring an authority-signed certificate has become much easier. If you need one from a globally recognized authority, commoditization has brought prices down. Most issuers have wizards and other tools to make obtaining and applying certificates as easy as possible. Even better, the Internet Security Research Group operates Let’s Encrypt, which issues free certificates recognized and accepted by most systems. They even have automation tools that you can use to greatly reduce the difficulty of replacing expired certificates in some cases.
If you operate a Windows Active Directory domain, then you have long had the ability to automatically issue and verify certificates for the use of every domain member, whether user or computer. We will demonstrate this in future articles. If you don’t have a directory, then you can still use Linux systems for internal certificate issuance with a bit more effort. If you primarily need certificates for local test and development activities, then you can use any Linux environment, whether a server, workstation, or the Windows Subsystem for Linux as a certificate authority. The next section of the article focuses on test environments.
The second problem with self-signed certificates: they no longer have the edge of convenience that they once had, and whatever remains can no longer override the security risks of using them.
Self-Signed Certificates Do Not Test Anything
In a perfect world, test environments would receive more attention than production environments because they have no consequences for mistakes and give opportunities to learn to correct them without harming a customer. In the real world, test environments usually receive only the briefest attention because all the things that we hope to catch in test usually survive into production, so we have to focus our efforts on keeping customers happy.
So, many administrators have developed a habit of using self-signed certificates, but only in “test” environments. However, such certificates do not allow you to test anything of value. TLS can use them for encryption, but you can verify that with a simple Wireshark trace. Certificates allow one party in a communication, whether an active transmission or reading at-rest data, to verify the identity of the author via a trusted third party. Your test environment should test that. Therefore, it should use authority-issued certificates just like your production environment. This point belongs to a larger one: your test environment should mirror your production environment to the best of your ability, not trim it down to the minimum. Otherwise, it doesn’t test anything.
While it might seem like a heavy lift, creating a certificate authority requires almost time or resources. The real trouble with one would be getting everyone to trust it. But, for test or internal environments, you don’t need to set your sights nearly so high. Also, don’t forget that you can use services like Let’s Encrypt if you need that higher level of trust.
This is not a standalone problem like the first two. Your takeaway from this section should be that self-signed certificates aren’t even good for testing purposes.
Our Intent for Future Articles
We plan to have articles on the following subjects:
- High-level explanatory information to demystify PKI and certificates
- Certificate authorities using Linux or Linux Subsystem for Windows
- Certificate authorities using Windows Server
- Automatically distributing certificates in a Microsoft Active Directory environment
- In-depth content on certificate components, such as X.509 attributes
While we build those articles, you can make use of an article that I wrote for the Altaro Dojo that walks through using Linux as an offline certificate authority with an online Windows Server subordinate. You can find sufficient how-to information in it to satisfy most of the purposes that I mentioned in this article.