SSL Intranet
- Home
- Products
- SSL Intranet
//Secure Internal Network Traffic with HTTPS connection
We are all used to seeing a padlock when we visit a financial services website whether it is a bank or a mutual fund or such. The idea of the padlock is to give us the confidence that the webpage on the server is with SSL/TLS certificate so that no one can read or intercept data on the network. Just like the SSL/TLS certificate on a public website, SecureNT Intranet SSL certificate is suitable for non-public intranet servers. It is installed on the organization’s local or wide area network.
Why use Intranet SSL Certificates?
People in charge of Cyber Security give great importance to the security of public-facing websites and applications. A lot of money is spent on Firewall, Traffic Analysis, Malware Detection, Network Access Control, etc. And very little attention is paid to the security of the internal network, where most valuable information is stored.
They assume that the internal network is quite secure. Why? Because everyone on the internal network is a trusted person. To a large extent, this is true as well. But what if an unhappy employee is there among the trusted people? What if a hacker gets access to an internal network? Since most important information is stored on the internal network, many unpleasant things can happen once someone with ill intent is inside.
Since Work from Home (WFH) has become routine, this issue has assumed great importance. Hackers can easily steal WFH credentials from unsuspecting non-tech-savvy employees. And once in, they can copy/manipulate crucial information before their unauthorized access is even noticed by the Cyber Security team.
What is an Intranet SSL Certificate?
An Intranet SSL certificate is a Private/non-Public SSL (TLS) Certificate issued by SecureNT as a Private Certifying Authority (CA). Technically, it is similar to the SSL certificates issued by Public CAs (like DigiCert, GlobalSign, Entrust, Sectigo, or Let’s Encrypt) but it is used on internal networks or private sites.
Thus, the Intranet SSL certificate is installed on the servers of an internal private network. After installation, whenever a user (client PC) on a local network connects to this server using a browser, all data flowing between the client PC and the server is encrypted and no one can read it, even with snooping tools. Thus, confidential data and passwords flowing on the internal network remain secure from unauthorized users and even hackers.
Please note that the SecureNT Intranet SSL certificate’s root certificate chain is not trusted by default on popular browsers like Chrome, Edge, Internet Explorer, Safari, Firefox, etc. This means that unless certain steps are taken, a client PC will get a “certificate not trusted” error when a user uses a web browser to access a website hosted on a Server with Intranet SSL. But these steps need to be taken once only. After those steps are taken, the client PC will always trust the Intranet SSL certificate.
How is Intranet SSL better than 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.
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.
- 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 makes the entire network and hence the organization vulnerable to malware and 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 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.”
- Root 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.
- Intermediate CA Certificate: Private Key is stored at PKI Infrastructure location to issue the End-entity SSL Certificates.
- End-entity SSL Certificate: This certificate requires both, Intermediate CA and Root CA Certificates to verify its identity and Trust Chain.
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.
