First, let’s see what is a Self-signed Certificate. A self-signed certificate is a Certificate issued by one-self to himself.
In this Certificate I say I-am-so-and-so and it is true because I-am-saying-it. There is no external validation by a trusted entity.
One can issue such Certificates very easily (in seconds) and they could be valid for very long periods without any limit. Hence many users use Self-signed SSL certificates on internal IPs or URLs.
While it is cheap and easy one should keep in mind the disadvantages. The main problem is that once created the private key is not stored separately in a secure place. It is usually stored in a PFX file along with the certificate with a weak or no password. And they are usually found on the file servers or local PCs. Any person with a bad intention can use the private key taken from the PFX file to decrypt the network traffic. So, it’s very risky to use self-signed certificates.
Also, Self-signed Certificates pose the following issues.
- Unlike CA-issued certificates, self-signed certificates cannot be revoked. Once compromised it needs to the located and replaced with a new certificate.
- Continued usage of Self-signed Certificates by end-users on internal networks can make them inclined to ignore “Security Certificate Error” warnings on public sites. This can make the organization vulnerable to malware and the loss of confidential data.
- Self-signed certificates’ private keys are not managed securely and systematically. This leads to an unknown number of certificates lying everywhere. And one loses track of who-what-when-how and why. Also, a private key could get into the hand of a disgruntled employee or a hacker leading to either loss of important data or spoofed certificates.
- Software developers routinely use Self-signed Certificates for different developer tools and software testing without any documentation as to who, what, when, how, and why. And these certificates many times end up in the production systems, making them vulnerable to failure due to certificate expiry and unforeseen attacks.
- When compromise happens brand reputation and customer trust are damaged.
Is there any way out?
For public websites, one should use Certificates issued by public Certifying Authorities only.
For internal networks, one can set up an Internal Public Key Infrastructure (PKI) authority which can create a non-public Root Certificate, and use this Root certificate to issue SSL Certificates for internal use on Intranets.
But, we recommend the creation of an Intermediate Certificate and using it to issue the Certificates for internal use on Intranets. By doing this Private key of the non-public Root Certificate can be stored away securely without any risk of it going into the hands of a disgruntled employee or a hacker. If you notice, all public Certifying Authorities take this route of “Trusted Certificate Chain” because of its high security.
But, setting up of Internal PKI could be quite costly due to the requirement of highly skilled people.