Installing HTTPS/SSL on Windows servers that have no access to the Internet

Question

We have some Windows servers that are behind a firewall, and have no access to the Internet. Some of them are Web Servers (for intranet), and some are application servers, database, file, etc.

Some of the applications require login, and due to the lack of SSL certificates, the browser will display a warning to the user whenever it sees in input field on the page.

We can't configure the Web Server to use HTTPS since it lacks the SSL certificate.

My Question is: Is there a way to configure the server to use HTTPS even though it has no access to the Internet?

If yes, then how can the certificate be installed on it? I understand that I must purchase a certificate from somewhere, but how do I install it on all of the servers?

Where can I read more about these things that apply to our setup?

Answer 1

When you have control over the clients that will connect to your servers, one appropriate solution would be to set up a self-signed internal certificate authority.

What you would do in theory is to set up a root certificate which should be kept secure and offline. Based on this one you would create child CA certificates that should be used to sign the actual server certificates. You would then need to deploy the appropriate public keys to all computers that connect to internal services to make the trust relationship work.

In a Windows environment, Microsoft’s documentation might be of some help: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/server-certificate-deployment-overview.

In a more open environment, there are several ways to proceed, usually based on OpenSSL and complementary tools. A web search engine is your friend there.

Answer 2

There are two ways, as I see it: either create a so called self-signed certificate or get a free one from a service such as Let's Encrypt.

Creating a self-signed certificate depends on your environment and the easiest way is to search for this on Google. For Linux and Apache, for instance, you could follow this recipe, but there are others as you will see.

Installing certificates depends on the server you are using and here I must ask you to check out the documentation for the one you have. It differs between Apache, Nginx, IIS or what-not, but all of these have excellent documentation

Answer 3

There are a number of options open to you.

To get a "real" certificate (i.e. one trusted by browsers by default) requires you to validate access to the domain. This is done by one of three ways:

1. Putting a file provided by the CA on the web server which the CA checks exists and so confirms you have access to the server. This is probably the most common way, but it is not an option for you since you are not publicly facing.
2. By adding an entry which the CA provides to your DNS which shows you have access to alter DNS records, which shows you effectively have access to that domain.
3. Answering an email sent to one of a select number of email addresses. This shows you have access to the main mail server and so must have access to the domain.

So you could use 2 or 3 to get a "real" certificate. The most popular free certificate authority Let's Encrypt only supports methods 1 and 2, and 2 depend on your DNS having an automated API to add entries so not always an option. Other CAs will support all 3 methods and guide you through how to do this - but usually charge for their services since it is manual in nature.

The other option is to get a wildcard certificate (e.g. for *.example.com) which could be used for any internal address (e.g. internal.example.com). This wildcard certificate can be confirmed in a similar way to above (though some CAs may not allow all of these verification methods for wildcard certificates. Let's Encrypt for example only allows wildcard certs to be issued via DNS-based validation). If you get a wildcard cert then this allows reuse on any servers under that domain (e.g. intranet.example.com, dev.example.com, etc.). That of course has other risks if sharing the key with multiple servers/owners/departments.

And finally, as others have mentioned, you can create an internal certificate authority to create self-signed certificated. These will not be recognized by browsers by default as they have not been issued by a recognized, "real" CA. However, you can add the CA root key to your computer so it is recognized. This is often a good option for corporate environments where you can ensure this root key is installed on all devices through a policy and so it effectively acts like a real certificate. Going into the full details of how to set this up is beyond the scope of this answer...