Install HTTPS
My server has no internet connection

Why HTTPS? I have no security concerns.

You can skip this section if you already know why you must be using HTTPS.

HTTPS is required for several reasons that are not "Security" driven.

Features since 2016 are being taken away from those on HTTP

Browsers, since 2016, have been removing features from HTTP, only alowing them in HTTPS. They promise they are going to (circa 2018.10) remove more features in the coming years until they force everyone to HTTPS.

  • Browsers, since about 2015, have been adding features for HTTPS that they don't allow in HTTP. As of 2018, it appears that all new features in most major browsers, are only available if you are running HTTPS.
  • In October 2016, a few browsers took away the ability to take photos and video from HTTP, this also took away our ability in HTTP to read barcodes.
  • Through 2017 and early 2018 more features were taken away that didn't affect us.
  • In late 2018, Chrome v71 took away our ability to work 'offline' except in HTTPS.
  • Some aspects of MRO (MC) may be already affected, and more for both MRO and MCe/MCxLE are 'promised' by the browsers.

Data Integrity

HTTPS provides data integrity:

  1. what was sent by the server is what is received by the client.
  2. Changes sent by the client are received by the server

While there are great security reasons for the above – there are great non security reasons. We used to (when we supported HTTP) among all our customers, get reports about once a week saying that data or files were corrupted. Usually minor, sometimes major. In the first 3 years of supporting HTTPS – we have so far had exactly ZERO reports of this from any users running in HTTPS. Why? Because the packets are encryted before sending, decrypted on receipt. They have procedures to ensure no changes (corruption – by accident or on purpose) occurred.

The common "security" response is that this avoids "man in the middle" attacks. This also solves non-malicious "attacks" like bad packet switching causing packet corruption, or electrical interference causing packet corruption. Bad messages don't decrypt and thus are simply resent. Users have a better experience without random "bugs" caused because of a bit flip while they were downloading the software.

With Internet access, HTTPS can be easy and free

Since 2016, LetsEncrypt.org has done an excellent job of making HTTPS management both easy and free, and many other companies have drastically reduced their prices due to this significant competitor.

So HOW do you install HTTPS without the server having internet access?

If you can, temporily expose the server to the internet

to get the certificate and periodically to update it (you can get excellent quality ones from LetsEncrypt for free)

Without internet exposure of the server your ability to provide HTTPS becomes harder. If you can (even temporarily) expose the server on the internet this process will be much simpler (see other documents for setting up HTTPS the easier ways).

The 2 options for SSL certificates when no internet exposure of the server is possible is: Paid Certificate Authorities and Self Signed Certificates.

Paid Certificate Authority

With a Paid Certificate Authority, you can have a wildcard certificate issued for your domain. Once you have gone through the ownership proof process, you will be able to install that certificate on servers that are not exposed to the internet. You can create an intranet DNS record like MC.<my domain>.com and with the wildcard certificate installed and DNS records or windows HOSTS records updated on clients, everyone should be able to connect.

Self-signed certificates

With self-signed certificates the process is harder, you will need to setup your own authority and install a root trust certificate on each client system. This process is out of scope for this article. After creating and issuing the certificate and working through the numerous edge cases where problems may occur. The result should be the same, successful connection over HTTPS with no error about the certificate.

What can go wrong?

  1. A certificate can be issued for the wrong NAME (subject name). The DNS name that the server uses needs to match a subject name from the certificate. For instance an IP address will not work when the server has a domain name certificate (or vice versa).
  2. "I can manually select to trust the connection." This doesn't work. The application and browser will initiate connections to the server that the browser will not allow you (the user) to approve, this will cause the application to appear locked up because a perfectly normal/safe operation was blocked by the browser due to the certificate not working correctly.