Self-Signed Certificates: What are they and why should you use them?

Read time: 4 minutes

In a time when keeping data and users secure on the Internet is so important, digital certificates have been used for a number of different purposes. Digital certificates are used for authentication, secure Internet connections, code signing, and more. This allows data-in-transit or data-at-rest to be protected from outside attackers. There are a number of different certificate types, but we will be taking a look at self-signed certificates today. The first question we have to answer is what exactly is a self-signed certificate?

What is a Self-Signed Certificate?

Depending on what the certificate is being used for, a self-signed certificate is a certificate signed by the same user or device using that certificate. This works for code being signed for internal use, or for an application being used by the creator, but not for software that is being used by external users. If an application or piece of software is being sent to external customers, then another type of certificate needs to be used. The reason for this is that a self-signed certificate will not be able to be verified when an external user attempts to use the software associated with that certificate.

When a user runs an application or piece of software, the certificate that signed that code is authenticated by the Operating System. You have likely seen that a pop-up occurs when a new software or application is downloaded and run on your computer. This pop-up checks the identity of the publisher of the certificate associated with the software. Additionally, the certification path is checked in the certificate as well. All of these details are checked to authenticate the publisher of the software. If the identity of the publisher cannot be properly verified, then the software would likely be deemed unsafe to run by the user.

Now, when using a self-signed certificate to sign software and applications, only the device which signed the certificate will be able to authenticate it. This is why self-signed certificates are not generally used for external software or applications. Instead, software publishers will use a Public Key Infrastructure with an external, and well-known, Root Certificate Authority which creates Certificate Authority generated (CA-generated) certificates. This allows the publisher to generate code signing certificates that can be recognized by any Operating System, thus authenticating the software sent to a customer and allowing them to trust that software or application enough to be downloaded and used on their device.

Pros and Cons

When dealing with self-signed certificates, there are many pros and cons that should be looked at before creating these types of certificates. Some of these we have already touched on, and others we will take a look at now.

Pros
Self-signed certificates are very easy to create, compared to other methods of certificate creation. There is no in-depth process, it is just the creation of a keypair and then the creation of the certificate itself. Other processes may require multiple steps and access to a Public Key Infrastructure (PKI) to create certificates.
Self-signed certificates are best utilized in test environments or for applications that just need to be privately recognized. Applications only for use within the organization they are created mainly use self-signed certificates.
Another reason that an organization may use self-signed certificates is that there is no reliance on another organization for the certificates to be issued or keys to be protected. Creating publicly verifiable certificates with a well-known PKI can require a lot of time for a certificate to be issued, causing hang-ups in the process of publishing and distributing software.

Cons
The most obvious issue with utilizing a self-signed certificate for code signing applications and software is that the certificate will not be recognized outside of the organization. A self-signed signature is only recognized by the device it was signed on, or within the organization it was generated in.
Self-signed certificates are not easily tracked within an organization. This causes a multitude of issues, especially in the case of the compromise of a self-signed certificate. Since self-signed certificates can be created at any time from any device, the certificate may not be known to be compromised for a long period of time, allowing the threat actor to misuse the certificate to suit their needs.
Self-signed certificates can’t be revoked. With CA-generated certificates, it is simple to lookup the private keypair associated with a certificate, but that is not possible with self-signed certificates.

Conclusion

There are a number of different types of certificates available to users for purposes ranging from authentication and communication to code signing. These types of certificates tend to fall into two different categories, self-signed and CA-generated certificates. As previously mentioned, self-signed certificates are mainly used in test environments or for software and applications used exclusively within an organization. For this reason, we at Encryption Consulting suggest organizations looking to use certificates for code signing setup a PKI for their organization or work with a public PKI for code signing certificates. To learn how Encryption Consulting can help your organization create a strong and secure Public Key Infrastructure for use within your organization, visit our website at www.encryptionconsulting.com.