This question is on the minds of CIOs of organizations whether they have 50 or 5,000 computers on a Local Area or Wide Area Network. They are located in their offices, branches, campus, and factories.
They are used in diverse ways:
- On their office network, users use Web applications like Office 365, Email, Service Management, SalesForce automation, Payroll, or Human Resource (HR) applications, to name a few. Also, some users work from home (WFH) using VPN to connect to the office network.
- Some organizations use Microsoft Active Directory infrastructure and also high-end applications like ERP, CRM, Analytics, etc where data is stored in a database like Microsoft SQL, Oracle, SAP Sybase SQL, MySQL, PostgreSQL, etc.
- They own a mix of Windows and Linux Servers hosting web applications. These servers may be on-premise or hosted in a data center.
When a web application like Office 365, SalesForce, SAP, etc. is hosted by the vendor, good security is already ensured by them. We are not considering these cases here. We are considering users accessing web applications hosted on the on-premise or data-center servers, over the LAN/WAN or VPN, connected by Fiber, MPLS, or leased lines.
Here, when a user connects to the web application, the server either does not have an SSL Certificate or uses a Self-Signed Certificate. In either case, anyone can snoop on the internal network traffic and get access to usernames, passwords, confidential files or information, or salary records. This ‘anyone’ could be a disgruntled employee or an IT Service engineer or even a hacker who has somehow sneaked into the internal network.
When users Work From Home they use VPN to connect to the Office Network. It is very important to encrypt the data on the VPN network. If not done, hackers can get access to the credentials and other important data from non-tech-savvy users.
Another use case is IoT (or “embedded devices”) that run web services on a local network without direct internet access, and the device manufacturer would like to offer secure access to the web services using an SSL Certificate.
Thus you need an Intranet SSL certificate when you use web applications, or have employees access the office network using a VPN; or an IoT device that requires local web services.
You need an Intranet SSL Certificate when you use
- Microsoft LDAP Server or any SQL database
- Web Applications on Intranet
- VPN over Unencrypted Network
- Web services over an HTTP connection
- Self-Signed SSL Certificates
But I use a Self-Signed Certificate already which does the same things!
You might say that a self-signed certificate is enough to protect you with encryption, but is it? Think again.
The PFX file containing the Self-signed certificate is stored somewhere on the internal network. Most of the time, such PFX files do not have a password or have extremely weak passwords like abc@123. If an unauthorized user gets access to it, he can use the Private Key stored inside the PFX file to decrypt the network traffic.
In most organizations, PFX files are not stored in a secure place, away from the internal network. They are casually created by the administrators and are routinely shared with users. This article explains these problems in detail.
Because of the above reasons, it is prudent to use Intranet SSL/TLS Certificates on the internal servers.
Can’t I set up my Private Certifying Authority?
Yes. But it’s very costly, requiring massive infrastructure and highly skilled personnel. Even large-size corporates find it prohibitively expensive. So, this option is almost non-existent for most organizations.
Large corporates using Windows Servers use Microsoft Active Directory Certificate Service (ADCS) to set up their own Certifying Authority and issue SSL Certificates. But, this route is for top corporates only. Please read this and this article to understand the difficulties.
I already have SSL certificates for my websites. Can’t I use them for Internal Networks too?
No. CA/Browser Forum does not allow Public CA’s like DigiCert, GlobalSign, EnTrust, Sectigo, Let’s Encrypt, etc. to issue SSL Certificates to IP Addresses (Internal or Public), Server Names, Local Hosts, or internal Web URLs.
Some of these CAs issue Intranet SSL Certificates using non-Public Root Certificates but at a high price. We take a similar approach but offer them at an affordable price.