Configuring different internal and external server names for FileHold

FileHold DMS clients use standard internet protocols to access the server and it is increasingly common for customers to want access to FileHold over the internet. In some cases, this is the only way the server will be accessed. This generally means you will use the HTTPS protocol to encrypt your data and that requires some extra configuration on your FileHold server.

For the purpose of this article, we will assume you have purchased your external domain name and pointed your domain name servers to your FileHold server internet address and opened port 443 on your firewall. If you have no idea what I just said, feel free to stop reading now, but stick around if you want a few acronyms or buzzwords to impress your friends with. Someone with Windows administrative skills should be doing this sort of configuration.

One of the first problems you need to solve is to acquire a certificate for your server as the HTTPS protocol requires it. You have two choices: create one yourself or purchase one. The first option is simple, but probably only practical for special cases such as testing. It will not be discussed further.

The second option will cost you a little bit of money every year and you will need to maintain your certificate as it will eventually expire, but it will automatically function with most browsers. Just do an internet search for “SSL certificate” and you will find plenty of options to purchase. Your seller will provide instructions for how to make a certificate request (CSR) for Internet Information Server (IIS).

By default, the installation of FileHold will have created a binding for HTTP on port 80 on the FileHold web site. The HTTP protocol may be fine to use for the application server talking to itself, but you will need to add a binding in order to watch for HTTPS traffic on port 443. Fire up the IIS management console, select your server then the FileHold web site. The far-right panel on the management page will have a link called “Bindings…”. Click this to bring up the bindings dialog.

You will see the binding for port 80 and you will need to add a new binding for port 443. There is no need to include a host name or check SNI (IIS 8.0 and later), but you will need to provide the certificate you purchased above. That’s it!

The hypertext transfer protocol (HTTP) and its secure variant HTTPS are functionally the same. The difference is that HTTPS utilizes secure socket layer (SSL) protocol or the newer transport layer security (TLS) to encrypt communication. This is what is used to secure your bank transactions and ecommerce sites. It is increasing used to secure public web pages in order to prevent web users from being tricked by fake web sites.

“Wait”, you say. Our IT policy requires HTTPS to be used everywhere even when the services are all on the same server. That does complicate things a bit, but it is still an easy configuration to setup.

The first thing you will need is a second certificate for your server. This is because your internal services will refer to themselves using the internal server name. The certificate you purchased was only for your external server name. The process of creating the second certificate is fairly straight forward and free.

There may be a small performance benefit to using the HTTP protocol for the services that are communicating on the same server. The big cost associated with HTTPS is the initial key handshake, but after that there is still a small impact to encrypting the data on-the-fly. So, start up time is slower and you will consume a few more CPU cycles with HTTPS.

From the IIS management console, select your server name and notice the icons that appear including one called “Server Certificates”. Open that option and you will see a panel on the right of the screen with a link called “Create Self-Signed Certificate…”. Click on it. You will be asked for a friendly name for the certificate. Choose something like “Local machine” or anything you can remember. Choose the “Personal” certificate store.

You could also use the “Web Site” certificate store, but generally that is only needed when you are hosting a lot of different domains on the same server, which is not normally the case for a FileHold server.

Now, get back to the binding dialog you used earlier. This time you will remove the HTTP binding and add another HTTPS binding. As before the port will be 443, but this time you will select the local machine certificate you just created. You are also going to provide a host name. When you created the certificate, the fully qualified domain name (FQDN) for the server was automatically added. Open the certificate and make a note of the name, then close the certificate and add the name to the binding.

One more thing is needed to complete this binding. Check the “SNI” option this time. This will enable TLS to exchange host names before deciding on the encryption details and allow IIS to pick the correct certificate for the name that is requesting access. Save your new binding and open the other HTTPS binding you created earlier. Check the SNI option for that binding also.

Server name indication (SNI) is a relatively new part of the TLS protocol that first became generally available in major browsers in 2006. All FileHold supported browsers support SNI.

The last step is to make sure the FileHold web configuration files use the FDQN for the local server name and HTTPS. Use the FHIT tool and choose the option to change the server name and protocol. The new server name is the one you made a note of from the certificate you just created. The protocol should be HTTPS.

That’s it, again! You now have a server where all internal and external communications are encrypted.

There may be some fine tuning you want to do to the server. Sometimes it is desirable to provide browser users with an option to enter an address with the HTTP protocol. When they do this you will want to correct their address to use the HTTPS protocol, but we will save that for another article. As always, the FileHold professional services team can assist you with special configurations.

Russ Beinder

Russ Beinder is the Chief Technology Officer at FileHold. He is an entrepreneur, a seasoned business analyst, computer technologist and a certified Project Management Professional (PMP). For over 35 years he has used computer technology to help organizations solve business problems.