In version 4.9.0 of S-Filer Portal, we have decided to address an important pain point with the solution: TLS configuration. We are a security company and we promote the use of TLS, but configuration of these certificates properly was complex and administrators would remain with unsecured connections internally. To address this, we decided to make the process easy!
Background Information on TLS and Trust
First a focused summary of TLS to understand what the feature is about.
In a TLS connection, the server has a private key, used to secure the connection, and a certificate corresponding to the private key. When the client connects, the server sends its certificate so that the client can communicate securely with it. But before the client uses the server’s certificate, it checks whether it is trustworthy. To do this, it checks two primary items on the certificate (and many other secondary items):
- The Subject Alter Name(SAN) of the certificate should match the address of the server to make sure that the certificate was issued for the right server
- The certificate is directly present in its Truststore or was issued by a Certificate Authority(CA) present in the Trustore
A Truststore is simply a list of certificates that are trusted by the client. This feature deals with adding (and removing) certificates in the Trustore.
Why was it complex in S-Filer/Portal?
Here is a typical deployment of S-Filer/Portal:
Most of the links in the diagram should be in TLS, so this represents quite a lot of TLS configuration. Before this feature, all of the keys and certificates needed to be imported using command line tools in the Java truststore. Further finding the right certificate to import usually implies using tools to connect and export the received certificate.
In terms of TLS in S-Filer/Portal, we have these use cases:
- The S-Filer/Portal Server acts as a TLS server for the configuration interface
- The S-Filer/Portal Server acts as a TLS server for the web services
- The S-Filer/Portal Server acts as a TLS client for the organization’s services (AD, LDAP server, Email server, ICAP server)
- The S-Filer/Portal Gateway(s) acts as a TLS client for the S-Filer/Portal Server
- The S-Filer/Portal Gateway(s) acts as a TLS server for the web interface presented to users
- The S-Filer/Portal Gateway(s) acts as a TLS server for FTPS connections
How can I view the truststore?
The configuration interface now includes pages to configure TLS trustores and private keys for both the S-Filer/Portal server and gateway.
In the treeview, new items were added to configure the certificates for the server and each gateway
We have added options to trust the default Java truststore (named cacerts) and on Windows platforms to trust the Windows certificate store. By default, these stores are trusted
These checkboxes control whether the certificates and keys in the java and Windows stores are shown in the list. Since they contain many entries, by default they are not shown
The private keys (key icon) and certificates (star icon) in the truststore are displayed in the list along with some information to help identify valid certificates and the system they are meant to secure
Individual keys or certificates can be deleted from the truststore if they are not needed or not trusted anymore
The Delete All button will remove all certificates from the truststore. Note that this only affects certificates added explicitly in S-Filer/Portal and doesn’t affect the default java truststore or Windows certificate store
The Import button shows the certificate import page (covered below). Further, in the S-Filer/Portal gateways, the “Import the certificate from the current server’s key” button is a quick way to get the gateway to trust the server certificate
Untrusted certificates is a list of TLS certificates that were received from a TLS connection but were not trusted using the current truststore. Administrators should review these and trust certificates that are needed for legitimate connections. See Which certificate should I import for more details on this approach
How can I import certificates in the truststore?
The “Import Certificate” page offers many alternatives to add certificates to the truststore. This assumes that you already know which certificate you should import in the truststore. If you don’t, see Which certificate should I import.
If you have a .cer, .der, .pem, .pfx or .p12 file you can drag it here or select it with the “Browse” button. The certificate will be read from the file and imported into the truststore. In the case of .p12 and .pfx files, the system will ask for the password to open the file
If you have the contents of the certificate directly, you can paste it in the box. This is usually a block of text starting with the line: “—–BEGIN CERTIFICATE—–”
This option generates an entirely new RSA key pair and corresponding certificate with the given parameters. This option generates a “self-signed” certificate
There is an additional method to add certificates to the S-filer/Portal truststore which doesn’t use the web interface at all, see How can I import certificates without the web interface?
How can I import a private key for use on the server-side of a TLS connection?
The same method mentioned in How can I import certificates in the truststore? can be used to import key pairs along with the corresponding certificate. Specifically, specifying a .pfx or .p12 file in the upload box will import the private key within.
How can I import certificates without the web interface?
There is an additional method for importing certificates to the truststore. In the installation folder there is a conf/certs.d folder. Any certificates added to this folder will be automatically trusted when the S-Filer/Portal Server or gateway starts.
This is useful for scripting or automated deployments where certificates need to be trusted without clicking in a web interface.
Which certificate should I import?
This question is tricky as it depends on the situation. These use cases should be considered:
- If the organization has a certificate authority (CA), all internal TLS certificates are usually issued and signed by that CA and the CA certificate should be imported in the truststore
- In a Windows organization, the CA certificate is usually already present in the Windows certificate store (which is trusted by default), so there is nothing to import explicitly
- When there is no CA, internal certificates are usually self-signed. In that case, the easiest solution is to configure the connection parameters to the various systems. The initial connections will fail since the certificates are not trusted, but the certificates will be added in the “Untrusted Certificates” store. Afterwards, looking into the “Untrusted Certificates” list will reveal the certificates received. Administrators should review these “untrusted” certificates and trust them if they are legitimate
How do I change the certificate used to serve the configuration interface?
This is the chicken and egg problem: the configuration interface is used to easily configure TLS cetificates, but it requires a TLS certificate to start!
On initial installation, the S-Filer/Portal server will generate a key pair and self-signed certificate and the configuration interface will use this key.If you need to change the certificate used, you can import the private key and certificate using the import functionality, however, you cannot yet indicate that this key should be used to serve the configuration interface. To do that, you still need to use the java keytool to retrieve the alias of the imported key and then write this alias in the config file for the key “cfg.configurator.private.key”. We are working on a command line tool that would help to make this task easier.
