Why are SSL Certificates required for Intranet Servers?
Does your business use browser-based web apps? Does your private LAN/WAN network have web-based access to CRM software, Accounting & Payroll apps Analytics and Web apps, private personnel info from HRMS, customer contacts from the CRM or Service desk, or other network apps that have information that should be secured within your company? Unless your intranet servers use an SSL certificate, browsers and other applications cannot create secure sessions to protect data being exchanged with Intranet servers.
If your organization’s LAN access is hacked, or if you have a rogue employee, packet sniffers can be deployed across LAN PCs. These can intercept vital trade information from apps on your network.
The Problem
Globally-trusted Certifying Authorities (CAs) are the best option as their Root certificates are already trusted by all web browsers and device clients. However, they only offer their SSL certificates to public fully-qualified domain names (FQDNs) such as iwebz.net, www.iwebz.net, ssl.iwebz.net, etc.
You are left with only two other options: self-signed SSL certificates and setting up and maintaining a local network CA. As you may already know, these are not scalable or practical solutions for small businesses. In both cases, it is a pain especially with a lot of devices, to add a trusted certificate to every client on the intranet/LAN after setting up the certificate on one or more intranet servers.
The Scalable and Practical Solution
Use an SSL certificate issued by a globally-trusted CA for the public FQDN of an intranet server. This saves you a lot of effort in creating & maintaining a local network CA or generating and setting up the certificate across each device on your intranet.
But given the restrictions of CAs issuing certificates to only public domain names, how is this possible?
Pre-requisites
- You will need a public domain name and you also need access to that domain name's DNS Management control panel.
- The intranet server does not have to be a web server, it can be an SFTP server, a MySQL database, or any software that uses SSL/TLS certificates.
- You should know how to request and install an SSL Certificate for that server software.
- The intranet server must have a static local IP address (IPv4 or IPv6) on the same private network as the intended users.
- The client browsers/apps need to have access to the Internet to look up the public DNS record for the local server IP.
Steps you need to follow
- Create a new sub-domain using the DNS Management control panel and use an A record or AAAA record to point it to your intranet/LAN server's static local IP address.
A record for an IPv4 address or AAAA record for an IPv6 address. - Request an SSL certificate for that sub-domain using a CSR.
It is recommended to request a Wildcard SSL Certificate with one-year validity to cover all sub-domains you may want to create with your domain name without needing to replace it often. - Select DCV method as DNS-based and add the DNS entry as displayed using the DNS Management panel.
- Set up the issued SSL certificate on the intranet server as you would on an internet server.
Now any user on the same intranet/LAN can access the intranet server using the public sub-domain and enjoy the benefits of a secured HTTPS connection.
The only flip side to this solution is that you need to own a public domain name with DNS management access and client browsers/apps need access to the Internet to look up the public DNS for the network IP address.
