Certificates for Internal Servers

I often get the question from customers "How do I make a browser trust my internal Intranet web server". Is it possible to use trusted certificates for Intranet servers? The short answer is yes. It is possible, and I'll show you two ways this can be solved. But what exactly is an Intranet server?

What Is an Intranet Server?

An Intranet (internal) server is one that runs on a private (home/business) network with a non-public IP address -- that is, any IPv4 address in the RFC 1918 range (e.g. 10.0.0.0, 172.16.0.0, 192.168.0.0) and any IPv6 address in the RFC 4193 range.

Why Should I Not Just Use a Self-signed Certificate?

Well, it is possible, but any person navigating to the server will get a nasty certificate warning. A brave person can click through it, but the https:// connection will be no more secure than a standard http:// (non-TLS) connection. In fact, Intranet servers with non trusted certificates are super easy to exploit with free tools from GitHub. A man in the middle attack can easily be performed on a non trusted https:// connection.

Unicorn Attacks

As a fun experiment, we can simulate a man in the middle attack on this DZone page by simply injecting the following unicornifying JavaScript code into the browser console. Most browsers let you open the console window by right-clicking on the web page to bring up the context menu. Select "Inspect" in the menu and click the console tab. Paste the JavaScript below code into the console to start the simulated attack 

xxxxxxxxxx

var script = document.createElement('script');

script.type = 'text/javascript';

script.src = 'https://www.cornify.com/js/cornify.js';

document.head.appendChild(script);

setInterval("cornify_add()", 5000);

A new rainbow or unicorn will appear on this page every five seconds as soon as you paste in the above code. Stop the attack by refreshing the browser window.

Solution 1: Act as Your Own Certificate Authority (CA)

A few years ago, we released a free tool that simplifies creating a complete chain of trust. The downside with being your own CA is that the root certificate must be installed in all clients (browsers) accessing the Intranet server. Installing the root certificate on a PC is easy, but it gets more complicated with tablets and phones.

Solution 2: Use the Let's Encrypt Certificate Authority

Let's Encrypt may be best known for providing free certificates; however, the real benefit with Let's Encrypt is the automatic certificate management protocol they invented. A web server (or plugin) that supports the automatic certificate management protocol ACME keeps the server's certificate up to date without any human interaction. The ACME protocol automates the CSR signing process, but just like any other CA, Let's Encrypt requires proof of ownership.

Proof of ownership can be provided by one of the two challenge options Let's Encrypt provides, http-01 and dns-01. Proof of ownership for a private Intranet server can only be provided via the dns-01 challenge option, which would normally require manual intervention unless a specialized DNS service manages this.

We have released two free products (MIT license) that automate installing Let's Encrypt signed certificates using the dns-01 challenge option. The two products include the source code and instructions for how to install the two products as a service on your own private VPS.

1. SharkTrust was designed for embedded web servers but can be used by any Intranet server as long as the required C code integration is followed.
2. SharkTrustX can be used "as is" without any code integration, but the Mako Server must be used as the Intranet server. See the article Secure Remote Access for a quick introduction on how to enable Let's Encrypt or, for a much more detailed tutorial, Automated Certificate Management for Private Web Servers.