- August 2, 2021
- Posted by: administrator
- Category: Sectigo
What Is a Self-Signed SSL Certificate?
A self-signed 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 certificates that are signed and issued by a CA because self-signed certificates are created, issued, and signed by the company or developer who is responsible for the website or software associated with the certificate. At a high-level, these self-signed certificates are based on the same cryptographic key pair architecture used in X.509 certificates. However, these digital certificates do not have the validation of a trusted third-party, like Sectigo. This lack of independent validation in the issuance process creates additional risk, which is why self-signed certificates are considered unsafe for public-facing websites and applications.
What Is the Purpose of Self-Signed Certificate?
Although they can be risky, self-signed certificates do have their uses. Chiefly, self-signed certificates are available at no cost and can be requested easily by any developer. They are able to be implemented on your timetable and not one provided by the third-party certificate authority. Often, they are 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 with after a set period of time, as is required by a CA. Although this seems convenient, it is one of the major concerns with these certificates, 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 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.
What Are the Problems Associated with Self-Signed Certificates?
There are numerous security warnings associated with self-signed certificates. Whenever a user visits a site that is using a self-signed certificate, they will be prompted immediately with a security pop-up warning displaying errors ike “error_self_signed_cert” or “err_cert_authority_invalid” that require the user to affirm 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. Consequently, if your website is labeled as not secure, you will be the among the first suspects of leaking private data in the eyes of your customers even if you did nothing wrong.
By having a self-signed certificate you are effectively on your own, without 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 Self-Signed Certificates?
As just discussed, using self-signed certificates carries a lot of risks, especially in a public facing capacity. Self-signed certificates 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. Using self-signed certificates with these sites 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 Are Certificates Created?
As mentioned above, a self-signed SSL certificate is any digital certificate that has not been issued by a trusted certificate authority. Still it is good to understand how to create a SSL/TLS certificate. Setting up the certificate 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 supported by many planforms, being one of the oldest cryptography systems for this process.
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 using. The certificate generated can be a root certificate or an intermediate certificate, 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, the certificate’s servername.crt file will be found in the current directory.
Again, self-signing certificates create significant risk when deployed in any environment and are not recommended. Visit Sectigo to learn more about trusted SSL/TLS certificates and other digital certificates.
NOTE:: This is article is copyright by Sectigo and we are used it for education or information purposes only.