Configuring FileHold to use encrypted client connections (SSL)

FileHold communicates between clients and server using an HTTP connection. By default, when the FileHold server is installed, an unencrypted HTTP connection is preconfigured. Before going live in production, IT departments typically will harden the FileHold server to improve its default security. One of the hardening activities is to prevent any outside network traffic to the server over an unencrypted connection.

This article is intended to be used by skilled Windows administrators. The information contained here is not describing a part of the FileHold product.

The most straightforward configuration is to block all unencrypted HTTP traffic and enable encrypted HTTPS traffic. In addition to enabling HTTPS traffic in firewalls, a “binding” for HTTPS traffic must be created in the Internet Information Server (IIS) that FileHold relies on to manage all communication. A more complex scenario is to disable all unencrypted HTTP traffic and usually requires a second HTTPS “binding”.

There are several questions whose answers will determine what steps will be needed to create secure connections.

Will users access FileHold using the fully qualified name of the FileHold server or will they use a different name? For example, if the server is named “myfilehold” in the domain “local” but users will access the server at “myfilehold.example.com” they are using a different name.
Does my organization policy require that unencrypted HTTP is never used? For example, it is common that FileHold is deployed for inter-process communication on the application server to use unencrypted HTTP protocol because the traffic never leaves the server and external access to HTTP is blocked by a firewall. However, some organizations force HTTP to always be disabled.
Does my organization have an internal certificate authority (CA)? A CA issues and verifies the certificates used to encrypt SSL traffic used with HTTPS. Often, organizations will have a domain controller or similar configured as a CA.
Does my organization use an external CA to create publicly accessible certificates?
Will all FileHold users have access to certificates internally generated by my organization?

Scenario 1 – Local access

Your internal network name is local and all users will access myfilehold server from my organization’s internal network as myfilehold.local. This configuration is also suitable for a test or development server.

You will need a certificate with the name “myfilehold.local”. It must be generated internally within your organization by your CA or self-signed and distributed as needed.
You will create an HTTPS binding in IIS linked to your internal certificate.
1. If your organization prohibits HTTP connections, you will set the FileHold configuration files to use your fully qualified server name myfilehold.local and your protocol to HTTPS using the FHIT configuration tool to change your server name and protocol.
2. If your organization does not have this prohibition, you will set your Windows (or other) firewall to prevent HTTP traffic from getting to the FileHold server from outside the server.

Scenario 2 – External access

You need an external name for your server such as myfilehold.example.com.

You will need a certificate from an external CA for “myfilehold.example.com”. You may need to allow some time for the external CA to properly qualify your organization if you do not already have a relationship with them. They will confirm that your domain name is owned by you. There will also be a series of technical steps required to acquire and install your certificate.
1. There are several commercial CAs such as IdenTrust and DigiCert.
2. Let’s Encrypt is a not-for-profit CA.
Once the certificate is installed on your FileHold server, you will create an HTTPS binding linked to this certificate.
1. If your organization prohibits using HTTPS, see scenario 2a.
2. If your organization does not have this prohibition, you will set your Windows (or other) firewall to prevent HTTP traffic from getting to the FileHold server from outside the server.

Scenario 2a – External access continued, no HTTP

Your internal network name is “local” and your server name is “myfilehold”. You should only use this option when absolutely required as it increases the complexity of your configuration, and it reduces the performance of your server by a small percentage.

Do not attempt to reuse your external certificate for this purpose. You can technically create a valid encrypted connection to FileHold in this way, but that will only help you with the communication aspect of operating the system. Certain scenarios in FileHold require authentication using credentials that combine your FileHold service user and server information. Using a different server name will cause certain parts of FileHold to fail as the credentials will not match.

You will need a certificate with the name myfilehold.local. It must be generated internally within your organization by your CA or self-signed and distributed as needed.
You will create an HTTPS binding in IIS linked to your internal certificate.
You use FHIT to change your server name and protocol in the FileHold configuration files.
You will delete the binding in IIS for HTTP.

Creating a self-signed certificate

There are a few cases for how certificates are created: public CA, internal CA (such as the CA role of your domain controller), and self-signed. As the name implies, with a self-signed certificate you are simply creating a certificate based on information you provide that is only as valid as you consider it to be. This approach is the most complex to manage when more than one machine is involved as the certificate must be distributed to each machine.

It is helpful to know that there are two locations for certificates maintained on the server. One is for user certificates, and one is for machine certificates. For this exercise, we will be working with machine certificates. Windows provides a general tool for managing certificates. Search Windows for certificates and select Manage computer certificates. You will need administration rights to open this program.

There are two certificate stores at this location we will be working with Personal and Trusted Root Certification Authorities.

You can also access the certificate stores using Powershell commands such a Get-ChildItem to get a list of contents in a similar way to getting a list of folder contents. For example, the following will list the contents of the Personal store. This is where the IIS binding tool will look for certificates.

Get-ChildItem Cert:\LocalMachine\My

You can also list the contents of the “Trusts Root Certification Authorities” with the command below. This is the first-place browsers or other applications making an SSL connection will look to see if the certificate the server provided is trusted. You need to be very careful with the contents of store as it supersedes all other ways certificates might be validated. Normally this list contains only the most trusted certificates in the world.

Get-ChildItem Cert:\LocalMachine\Root

If you are building a development or test server, you may be able to simply select the option to create a self-signed certificate directly in IIS management. From the server root, choose “Server Certificates” and open the feature. You will see a list of any certificates that are already on the machine and available to use with a binding in IIS.

When you click Create Self-Signed Certificate a certificate for the server will be added to the Personal and Trusted Root Certification Authorities store making it immediately available to be used in a binding or to validate a client request.

If you need this self-signed certificate to be used in a production environment, you cannot use the method in IIS as it fails the certificate validation in the latest versions of Windows. However, you can still create a self-signed certificate using a few lines of Windows Powershell 11 or 2022. It can also be done with older versions of Powershell, but the New-SelfSignedCertificate cmdlet in older versions cannot accept a hashtable as a parameter.

The following code should run on the machine it will be validating. It will create a certificate that is valid for 10 years from the date it is run. It will add it to the Personal and Trusted Root Certification Authorities stores and export a copy to a file for use on other machines. It also gives it a friendly name on the server including the current date and time to make it easy to find when you are setting up a binding.

$parms = @{
   DnsName = ([System.Net.Dns]::GetHostEntry([string]$env:computername).HostName)
   NotAfter = (Get-Date).AddYears(10)
   CertStoreLocation = 'Cert:\LocalMachine\My'
   TextExtension = @("2.5.29.37={text}1.3.6.1.5.5.7.3.1")
   KeyUsage = @("DigitalSignature", "KeyEncipherment", "DataEncipherment")
   KeySpec = 'KeyExchange'
   FriendlyName = "Self-$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMddhhmmss')"
}
$cert = New-SelfSignedCertificate @parms
$CertStore = New-Object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList 'Root', 'LocalMachine';
$CertStore.Open('ReadWrite');
$CertStore.Add( $cert );
$CertStore.Close();
$cert|Export-Certificate -FilePath "Self-$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMddhhmmss').cer"|Select-Object -Property Name

The file created by this Powershell will have the same name as the friendly name with a CER extension. You can simply copy it to any machines that will connect to your FileHold server, right click on the file to install. Select the Local Machine location and the Trusted Root Certification Authorities store. You can also import it using the Manage computer certificates tool or Powershell.

Creating an IIS binding

The binding concept in IIS is used to map a combination of protocol, host name, TCP port, and certificate to a web application. Generally, with most FileHold implementations, only the protocol and certificate are needed. The FileHold server installer automatically creates a binding for HTTP with the default port 80. Out of the box, this is the only way to connect to FileHold.

http://<<myserver>>/fh/filehold/webclient/libraryform.aspx

If you are adding one HTTPS binding, whether using an external server name or internal server name, all that is needed is the protocol and correct certificate. Clients accessing the server with HTTPS will need to use the exact server name in the certificate.

If you are adding two or more HTTPS bindings, you will need to check “Require Server Name Indication” (SNI) and provide the fully qualified host name for each binding and it must exactly match the name in the certificate. See our blog article for a more in-depth discussion.

Bindings can be managed with Powershell but the IIS manager is one of the simplest methods for creating or editing bindings. Simply select the FileHold web site on the left. You will drill into the server, then Sites and in most cases select Default Web Site. This is the name of the FileHold web site created by default in the server installer.

The Action panel on the right will now have a link Bindings…. Clicking it will bring up the Site Bindings dialog.

The dialog is straightforward, and this is not intended to be comprehensive instructions to cover every possible scenario. When you choose a certificate, you will have a list of friendly names for all the valid certificates in the Personal store.