Updated: October 13, 2022
A self-signed SSL certificate is a digital certificate that’s not signed by a publicly trusted Certificate Authority (CA). Self-signed certificates are considered different from traditional CA signed certificates because they are created, issued, and signed by the company or developer who is responsible for the website or software associated with the certificate, rather than a CA.
At a high-level, these self-signed certificates are based on the same cryptographic private and public key pair architecture that’s used in X.509 certificates. However, these digital certificates do not have the validation of a trusted third-party CA, like Sectigo. This lack of independent validation in the issuance process creates additional risk, which is the problem with self-signed certificates. They are considered unsafe for public-facing websites and applications.
Purpose of this Certificate Type
Although they can be risky, self-signed certificates do have their uses. Chiefly, they are available at no cost and can be requested easily by any developer. They are able to be implemented on your own timetable and are often used in internal testing environments or web servers that are otherwise locked down to external users.
Additionally, organizations have the benefit of knowing that self-signed SSL certificates encrypt the applicable incoming and outgoing data using the same methods as other, paid SSL/TLS certificates.
Self-signed certificates do not expire or need to be renewed after a set period of time, as is required by a CA certificate. Although this seems convenient, it is one of the major concerns with this option, as they cannot comply with security updates in response to discovered vulnerabilities, nor meet the certificate agility needed to secure today's modern enterprise. As such, this method of authentication is rarely recommended.
Additionally, revocation of certificates is not possible with self-signed certificates, which exposes the cryptography used to external threats should the certificate be forgotten or remain on systems open to malicious actors. Unfortunately even so, some IT departments believe that the costs of certificates issued by Certificate Authorities outweigh the reduced risk of additional validation and support.
Risks & Problems Associated with Self-Signed Certificates
There are numerous security warnings associated with self-signed SSL certificates. Whenever a user visits a site that is using this certificate type, they will be prompted immediately with a security pop-up warning displaying errors like “error_self_signed_cert” or “err_cert_authority_invalid” that require the user to confirm that they would like to proceed. These errors are prompted by the user's browser, and not the website itself, adding additional legitimacy to their concerns while introducing an additional step to visiting the website. No modern web browser trusts self-signed certificates and will not display the padlock symbol or HTTPS status for the domain name.
These warnings create fear and uneasiness for visitors to a website. They give the impression that the site may be compromised and that the website may not properly secure their data. Visitors will be tempted to avoid these websites and visit competitors that do not prompt security warnings upon visiting.
Understandably, visitors will be unlikely to share any personal or confidential information on a website that their trusted web browser tells them could be lacking proper security measures. This caution is for good reason as self-signed certificates can be exploited. A popular method is a man-in-the-middle attack, which allows the data shared via TLS/SSL protocol to be seen, exposing visitors to identity theft and system intrusion.
By choosing this type of SSL certificate, you are effectively on your own. This means you don’t have the backing of a trusted certificate authority and application of the latest cryptographic methods necessary to ensure proper authentication and encryption of data, devices, and applications.
Should I Use This Type?
As discussed, using self-signed certificates carries a lot of risks, especially in a public facing capacity. They are incredibly risky for any website that handles any private information including health, tax, or financial records. Exposure of this information not only damages brand trust but can harm an organization financially through fines and penalties by ways of applicable privacy regulation.
Many assume that using self-signed certificates internally carries no risk when deployed in areas such as employee portals or communication sites, but that is not true. They will still cause browser and security warnings. As these warnings can be ignored, organizations will often instruct their employees to do so. The safety of the internal site is assured, so this carries little harm directly. However, this can inadvertently cause the employees to get used to ignoring those types of warnings. That type of behavior may expose the organization to increased risk and opportunity for vulnerability.
How to Create a Certificate
While setting up a self-signed certificate is not recommended due to the security risks involved, setting up the configuration file and completing the issuance process is straightforward, depending on your environment, like Apache or Ubuntu Linux servers.
Generate a Private Key
To create the SSL certificate both a private key file and a certificate signing request (CSR) are necessary. The process begins with requesting a private key from your CA. Private keys are cryptographic keys generated using algorithms such as RSA and ECC. RSA keys are one of the oldest cryptography systems for this process and are supported by many planforms.
Though self-signing certificates are not recommended, here is a code example to generate a key with the following command:
openssl genrsa -aes256 -out servername.pass.key 4096
The command will prompt you for a passphrase. The passphrase can be utilized by the CA to authenticate the certificate owner if the certificate needs to be revoked for any reason.
Generate a CSR
Once generated, your private key file will now be located in your current directory as servername.key and will be used to generate your CSR. Here is a code example for the certificate signing request for a self-signed certificate:
openssl req -nodes -new -key servername.key -out servername.csr
Then, you will need to enter several pieces of information including organization, organizational unit, country name, state, locality, and common name. The common name is typically the domain name (dns) or IP address of the location.
After entering this information, a servername.csr file will be located in the current directory with the servername.key private key file.
Issue a certificate
Finally, a new certificate (.crt) is generated from the server.key (private key file) and server.csr files. The certificate generated can be a root certificate or an intermediate one, depending on your application of the chain of trust. Here is a command example for generating a new certificate:
openssl x509 -req -sha256 -days 365 -in servername.csr -signkey servername.key -out servername.crt
Similar to the previous step, its servername.crt file will be found in the current directory.
Again, self-signed certificates can create significant risks when they are deployed in any environment and this method is not recommended. Visit Sectigo to learn more about trusted SSL/TLS certificates and other types of digital certificates.