Key Manager Plus » Features
Last updated date : 03 Apr 2023

The need for self-signed certificates

CA-signed certificates offer the highest level of trust and security. While they're the ideal option for most cases, they may cost as much as $60 per certificate per annum. Businesses usually employ thousands of certificates for intranet communications and in test environments. In such cases, trusted CA-signed certificates may not be required and other cost-effective options like self-signed SSL certificates can be considered.

How are self-signed certificates different from public CA signed certificates?

Public CA signed certificates are signed by trusted vendors who verify the identity of the entities before issuing them certificates. These certificates thus carry a high level of trust and are often used on public websites that handle sensitive operations such as financial transactions. Self-signed SSL certificates, on the other hand, are signed and issued by the same entity and are only recommended for non-sensitive internal use. CA signed certificates are also generally harder to brute-force than self-signed certificates are, and are relatively secure from other cryptographic attacks.

Another difference is the validity period of these certificates. The validity of self-signed SSL certificates is set by the administrator generating them. However, CA signed certificates have shorter validity to stay in alignment with the latest security recommendations.

Benefits of using self-signed certificates

Self-signed certificates are easy to generate, faster to deploy, and involve no additional cost. You can generate them from your terminal and deploy them across your internal network wherever required. However, owing to their limitations, the benefits of self-signed certificates are limited just to cost and ease of deployment.

How to generate a self-signed certificate?

You can generate a self-signed certificate from your device's terminal using a software library like OpenSSL. This process involves three steps: creating a private key, generating a certificate signing request, and generating a self-signed certificate.

  • Open your terminal, then run the following command to create a private key file and a public certificate with a validity of 365 days.
  • Specify the common name and other details when prompted. The common name is the fully qualified domain name for the system that will employ your certificate.
  • To securely transfer or use your private key and certificate as a P12 bundle, run the following command

You can thus deploy these certificates wherever required.

Risks of using self-signed certificates

Although self-signed certificates are cost-effective and easy to use, businesses must be aware of some of the threats they pose:

01. Untrusted by browsers

Modern browsers maintain a pre-installed list of trusted certificate authorities (CAs). When a website presents a signed TLS/SSL certificate from one such CA, the browser will trust and establish a secure communication. Since self-signed certificates are issued and signed by the same entity, by default, browsers do not trust them. Users will thus be greeted with a warning message detailing that the communication may not be secure. This creates distrust amongst users and may drive away potential customers from your website. Self-signed certificates are thus not recommended on public domains.

02. Revocation troubles

Although certificates are designed to secure data in transit, they can be compromised due to potential vulnerabilities. In such cases, one would want to revoke compromised certificates instantly. This can easily be done with certificates signed by public CAs, which employ a centralized revocation mechanism.

Public CAs employ a Certificate Revocation List (CRL) which includes details such as serial number and date of revocation of a certificate. Applications and devices can reference the CRL to verify their certificate's validity. Either through its own auditing process or through intimation from the organization, the CA can be made aware of certificates that need to be revoked. This way, even if an organization manages thousands of certificates, they can all be instantly revoked as and when a need arises.

Self-signed certificates have no such centralized mechanism in place to revoke certificates automatically. Businesses would either have to revoke certificates manually or build their own CRL setup, which would defeat the cost-effective nature of self-signed certificates.

03. Vulnerability to attacks

Self-signed certificates may have inherent flaws that make them vulnerable to threats. For example, self-signed certificates generated with a weak key can be vulnerable to brute-force attacks. Similarly, since self-signed certificates can have extended expiry dates, the encryption algorithms used to generate the certificates could potentially become outdated in the future. Such vulnerabilities can be a deterrent when opting for self-signed certificates.

04. No technical assistance or financial cover

Public CA signed certificates often come with insurance that offers financial compensation to businesses if the certificates were to be breached. Businesses can also avail technical assistance for certificate installation and configuration, and other troubleshooting needs. Such benefits will be absent when you opt for self-signed certificates.

Bottom line: Are self-signed certificates secure?

It depends. While self-signed certificates can help you secure your data in transit, it has its own limitations, so be mindful of the following:

  • Use them sparingly in internal, less-sensitive environments.
  • Use strong encryption algorithms like RSA with a minimum key length of 2048 bits when generating your certificates.
  • Keep your private keys secure in an offline device that has restricted access.
  • Set expiry dates to under 2 years. This will help you stay up-to-date with latest encryption standards and also reduce the opportunity window for an attacker to exploit a compromised self-signed SSL/TLS certificate.
  • Educate your users about the perils of using self-signed SSL certificates and ensure they use them sparingly.
  • Adopt a certificate lifecycle management solution like ManageEngine Key Manager Plus. It'll help you discover and manage all self-signed and CA signed certificates from one place, send timely renewal reminders, automatically generate and deploy new certificates, and do much more.