What is a Self-Signed Certificate and How to Create One
Updated: December 4, 2023
A self-signed SSL / TLS 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 trusted 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, they do not have the validation of a trusted third-party CA, like Sectigo, meaning the certificate is not chained to a root CA or intermediate certificate like those issued by a trusted CA. This lack of independent validation in the issuance process creates additional risk, which is the problem with using self-signed certificates. They are considered unsafe for public-facing websites and applications and are typically used only in internal development and testing environments.
Purpose of this certificate type
Although they can be risky, self-signed certificates do have their uses and carry some advantages. They are free, easy for developers to request, encrypt the data using the same methods as paid SSL certificates, don’t expire, and revocation is not possible. However, when it comes to overall security, the risks typically outweigh the benefits.
The main advantage of a self-signed SSL certificate is that they are available at no cost and can be requested easily by any developer. They are able to quickly 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.
Organizations do 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 as it means 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. This exposes the cryptography used to external threats should the certificate be forgotten or remain on systems open to malicious actors. The risks associated with these certificates often outweigh the benefits as cybersecurity is paramount for any organization.
Risks and errors associated with self-signed certificates
There are numerous security warnings and concerns associated with self-signed SSL certificates, which is why they are hardly ever recommended.
Security warning pop-ups
Whenever a user visits a site that is using this type of certificate (which is never recommended on a public-facing site), 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 the user’s concerns while introducing an additional step to visiting the website. No modern web browser trusts self-signed certificates and the browser 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.
No certificate security updates or revocation
As mentioned earlier, your own certificates don’t need to be renewed because they never expire. This means they are never updated or changed to fix vulnerabilities or meet the newest security standards. This leaves your environment vulnerable to hackers and cyberattacks.
Similarly, since they can’t be revoked, this also means old certificates may be living in environments without staff knowing. This can lead to increased risk of certificates being exploited. A popular method of exploiting a self-signed certificate 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.
Self-signed certificate in certificate chain error
If a developer or IT team is trying to use a self-signed SSL certificate, they may internally come across the “self-signed certificate in certificate chain” error if using OpenSSL. In SSL/TLS communications, trust is established through a chain of certificates, leading back to a trusted root CA. When a self-signed certificate is encountered in this chain, it breaks the trust model, as this type is not inherently trusted.
Certificates issued by a trusted CA have a chain of trust leading back to that CA, ensuring their legitimacy. A self-signed certificate, however, is created and signed by the entity presenting it, not by a trusted CA. Because of this, they are not automatically trusted, as there is no external validation of the entity's identity. This presents a security risk, as it could allow an attacker to present a fraudulent certificate, potentially deceiving clients into establishing a secure connection with a malicious server.
This error that comes up can be bypassed, but it is given as a security measure to alert of the potential risk associated with a self-signed certificate.
Should I use a self-signed SSL certificate?
By choosing this type of SSL certificate, you are essentially 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.
These certificates carry a lot of risks, especially in a public-facing capacity. They are incredibly risky for a 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. For these reasons, they are never recommended on public-facing websites or applications.
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 self-signed certificate
While self-signed certificates are 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.
Avoid the risk
Self-signed certificates can create significant risks when they are deployed in any environment, internal or public-facing, and therefore this method is not recommended.
Contact Sectigo to learn more about our trusted SSL/TLS certificates and our certificate lifecycle management platform.
Related topics: