Daring Data-Theft is a video that explains the consequences of using self-signed certificates.

When customers use self-signed certificates to encrypt data on the internal network, data theft occurs. The use of SecureNT Intranet SSL for internal web applications protects customers from costly data theft.

So the question is what is a Self-signed Certificate?

A self-signed certificate is a Certificate issued by one-self to himself.

In this certificate, one says “I-am-so-and-so and it is true because I-am-saying-it.” There is no external validation by a trusted entity about this assertion.

One can issue such Certificates very easily (in seconds) and can be valid for long periods without any limit. Hence many users use Self-signed SSL certificates for internal IPs or URLs.

Self Signed Certificate

While it is cheap and easy, it comes at a huge price that is paid by way of data theft. The main problem is that once created the private key is not stored separately in a secure place. It is stored in a PFX file format (PKCS #12 or P12) along with the certificate with a weak or no password. And these PFX files are usually found on 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.  As a result, using self-signed certificates is extremely dangerous.

Also, another big issue is that until the customer loses data he does not learn about the private key compromise. It’s similar to cancer, it spreads in the system without anyone realising the fact. But when cancer strikes, it strikes hard.

Also, Self-signed Certificates pose the following issues.

  1. Unlike CA-issued certificates, self-signed certificates cannot be revoked. Once compromised, it needs to the located and replaced with a new certificate.
  2. 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 makes the entire network and hence the organization vulnerable to malware and loss of confidential data.
  3. 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.
  4. 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.
  5. When such a compromise occurs, it causes irreparable loss of brand reputation and customer trust.

How is Intranet SSL better?

For public websites, one should use Certificates issued by public Certifying Authorities only. They use a minimum two-level “Certificate Chain of Trust”, explained below.

For internal networks, one can set up an Internal Public Key Infrastructure (PKI) authority which can create a non-public Root CA Certificate, and use this Root CA certificate to issue SSL Certificates for internal use on Intranets. Here, there is a direct one-to-one relationship between the Root CA Certificate and the issued Certificate. But, this is one level of the hierarchy, and it is not enough.

We recommend creating an Intermediate CA Certificate using the Root CA Certificate; and using it to issue the SSL Certificates for internal use on Intranets. This is called a two-level “Certificate Chain of Trust.”

  1. Certificate Chain of Trust HierarchyRoot CA Certificate: Private Key is used once to create an Intermediate CA Certificate. It is stored away from the PKI Infrastructure in a secret and secure place.
  2. Intermediate CA Certificate: Private Key is stored at PKI Infrastructure location to issue the End-entity SSL Certificates.
  3. End-entity SSL Certificate: This certificate requires both, Intermediate CA and Root CA Certificates to verify its identity and Trust Chain.

Certificate Chain of Trust in detail

The roles of root certificate, intermediate certificate, and end-entity certificate as in the chain of trust.

Here, since the Private key of the Root CA Certificate is stored away securely, there is no risk of it going into the hands of a disgruntled employee or a hacker. All public Certifying Authorities also take this route of “ Certificate Chain of Trust” because of its high security.

In the case of Self-signed Certificates, there is no Trust Chain. The Private Key of the Root CA is stored within the PFX file. And these PFX files are stored on local PC or on Servers. They have no or weak passwords. If anyone with ill intentions gets to access these PFX files, he can manage to get the Private Key. He can use the Private Key to monitor the network traffic in unencrypted form on the internal network using sniffer tools. So, usage of Self-Signed SSL is fraught with severe data security risks.

But, setting up Internal PKI could be quite costly due to the requirement of highly skilled people. That’s where SecureNT Intranet SSL Certificates come in, to offer an easy solution. Just buy Certificates from us as and when required.