Enable HTTPS on a private network

Solution 1:

If your internal domain name matches an external domain name (e.g. sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of example.com assuming whoever owns [email protected]/[email protected]/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.

If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like sales.corp.example.local), then your only option is to use an internal CA.

If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).

Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.

As an aside:

The customer installs the software and it is good to go

That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:

• Customer may not have internet access from the host so you can't contact an external authority
• Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them
• Customer may require auditing of all certificates being issued for internal hostnames

In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.

Solution 2:

No manual steps allowed. The customer installs the software and it is good to go.

If you do not control end user devices, no additional steps means you must use a CA already in their root certificate stores (OS or browser). The customer's internal PKI could sign your certificates, but that assumes they have one, and it won't work for unmanaged devices. Which leaves a well-known "public" CA.

The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)

Ownership challenges need not be from the host that gets the certificate. You mentioned Let's Encrypt, their DNS challenge can be done from any Internet visible DNS. Including wildcards, so you can issue *.present.example.com.

Solution 3:

In my company we've got multiple Intranet-only web sites. Due to recent/current browser policy changes we've been setting them up with HTTPS/TLS support.

As these sites are for internal use only we decided to set-up an in-house certificate authority using the Microsoft Active Directory Certificate Authority (MS AD CA) service. Additionally we're using [Company Name].local URLs for the websites.

Using the AD CA service we created a RootCA certificate which gets distributed to all domain connected systems via the domain controller. Using the AD CA service we are then able to issue certificates for the various internal websites and devices with web interfaces.

We then use the active directory DNS service to set-up the [Company Name].local domain to assign the correct IP-addresses to the correct URLs. As the internal AD DNS is the primary DNS for our network.

The only issue we've had with this approach is the fact that the Firefox browser doesn't use the Windows certificate store and needs to have the created RootCA certificate imported manually. From my limited research it does seem to be possible to automatically import the RootCA certificate into the Firefox certificate store but due to the limited amount of Firefox users we decided to go the manual approach. Additionally if I recall correctly there is a feature request ticket pending with the Firefox development team to enable access to the Windows certificate store.

This seemed to use to be to most robust solution for our situation, your mileage may differ :)

For any external facing sites we use certificates from reputable sources.