What is a Self-Signed Certificate?

Iliya Garakh, CTO -

The SSL/TLS protocol’s job is to ensure security through authentication. It was designed to encrypt data transmitted over open networks and, as a result, protect against interception and spoofing attacks. TLS also authenticates communicating parties, which leaves us with a pretty trusting environment. It goes without saying that security through authentication is essential for a successful business in the 21st century.

If we closely observe the way in which SSL works, it becomes very clear very fast, that to establish the ‘trusting environment’, SSL certificates need to be signed and validated by a trusted Certificate Authority (CA). Now, while everyone trusts the CA, by extension, they are able to trust those with its certification. Traditionally, organizations have used CAs to sign their SSL/TLS certificates, but with an influx of digital products, a huge amount of software being developed and tested in addition to an all-time data breach record, many companies are switching to self-signed certificates.

What is a Self-Signed SSL Certificate?

A self-signed certificate is a digital certificate that hasn’t been signed by a publicly trusted CA. Instead, it is issued and signed by the entity that is responsible for the software. This, on the one hand, makes deployment pretty frictionless, but on the other, it comes with additional risk, especially when poorly implemented.

Although they can be risky, self-signed certificates are incredibly widespread. These certificates are available with no associated costs and can be requested easily by anyone, which is fantastic for internal testing environments or web servers that are otherwise locked for external users. Moreover, such a certificate still uses the same encryption methods as other, paid SSL/TLS certificates – that’s a piece of very good news for organizations because nobody wants their data leaking. As long as the CA doesn’t require a certificate expiry date, a self-signed certificate may be issued once and used till the end of time. This is used, for example, when working on some secret projects or simply with internal data.

For many companies that use self-signed certificates, the biggest advantage is, of course, independence. All security infrastructure is encapsulated inside the internal network, so even if such a network isn’t connected to the web at all – it’ll still work as intended.

Although this looks very convenient on the surface, it is one of the major concerns when dealing with these types of certificates. Offline, they aren’t able to receive security updates in response to discovered vulnerabilities, nor meet the certificate agility which is essential to secure today's modern enterprise.

Another challenge that arises when dealing with self-signed certificates is that responsible departments often lack visibility over how many were issued, where they are used, by whom, and also how the private key is stored. It’s hard enough to keep track of certificates issued by different public and private CAs. It’s almost impossible to track all self-signed certificates without an additional request process.

Pros:

  • Fast and easy to issue;
  • Useful in test environments;
  • Flexibility;
  • Independence;
  • No expiration date.

Cons:

  • No security updates;
  • Can’t be easily revoked;
  • Lack of visibility and control.

Let’s imagine that our internal network has been breached. If we use self-signed certificates, there is literally no way of knowing if it, and private keys associated with it, have been compromised. Once compromised, such a certificate may be used to spoof identities and gain access to important data, especially considering the fact that, unlike CA-issued certificates, self-signed certificates cannot be revoked and, as we mentioned before, have no expiration date. You cannot simply ‘revoke’ a private key in such a situation.

So, why are self-signed certificates still in use? The simple answer is that it’s convenient. The routine manual process of submitting a certificate signing request (CSR) and waiting hours for verification is just horrible. To save time and frustration, it makes more sense to opt for self-signed certificates.

So the biggest question on self-signed certificates of any type is not how to issue them, but how to properly implement them inside an organisation. It’s like making sushi – the recipe is very simple, but the devil is in the details.

Some risks may be indirect – let’s imagine we’re looking to use a self-signed certificate to provide access to an employee portal. It will cause any default browser to alert the user with warnings. As these alerts can be ignored, many organisations tend to instruct their employees to do exactly that – ignore warnings. The safety of the internal portal is assured, so there is no direct harm, but, at the same time, employees ‘learn’ to ignore alerts and warnings the same way we all ignore ads on websites. Such practices make the organisation overall more vulnerable. The crux of the matter is that employees just don’t provide essential feedback on time if something goes very wrong.

To get the best out of self-issued certificates and mitigate the risks involved, we recommend using OpenSSL to issue certificates. It is de facto an industry standard. But, as mentioned before, this is not enough. Correct implementation is even more important than the tools used. After all, a top of the line DeWalt grinder is going to be useless if you’re using it to hammer in a nail. So, when implementing a self-signed certificate try to follow these best practices:

  • Limit the expiration period, it should be as short as possible. Never use certificates that don’t feature an expiry date.
  • Limit usage. Never create ‘universal certificates’ that open all doors at once.
  • Use a meaningful and informative ‘subject’ record. Everybody should understand what the certificate is being used for.
  • Make sure that the algorithm used for the signature is at least SHA256WITHRSA (which is the default in OpenSSL).
  • Create only encrypted private keys.
  • Use elliptic curve keys as opposed to the default RSA ones; they provide a number of benefits over RSA.
  • Most importantly, create a repeatable/scriptable process for issuing certificates and keys. OpenSSL is a de-facto standard command-line tool that can be used as the basis for this process.

Self-signed certificates are fast and easy to use, they are great for test environments, or when providing encrypted access to internal data. They provide independence and are free to use. That is why they are used across the board in so many companies. On the whole, there’s really no other way to do things right. But remember, SSL/TLS self-signed certificates are like fugu fish – it is delicious when cooked well, but you’ll drop dead if the chef’s on his lunch break.