SSL Certs and The Chain Of Trust

In the fun world of FileMaker Server configuration, one of the key tasks is to set up the domain name and an associated “SSL Certificate” — the cert verifies the server’s identity, and provides an encryption key used to encode data that flows between users and the server.

This is all marvelous stuff of course because it means that there’s no-way for someone to trick you into connecting to a different server than the one you meant to and because all the private personal and business data that is zooming along the wires and airwaves between you and the server is indecipherable to anyone else.

But there are some tricks to setting up secure certificates and how they work so we thought we’d share a recent experience we had when one of the certication authorities dropped the ball and broke what’s called the “Chain of Trust”…

Chain Of Trust

When you purchase and install an SSL Certificate on your FileMaker Server, you expect that you own the whole ‘kit and caboodle’, or at least you do for the timeframe you have purchased the certificate for.

To some degree that is correct, but there is a chain of trust that sits above your certificate that you ought to understand… in essence there are many organisations that can issue certificates, but only a few that are known and trusted by an operating system.

Therefore an issuer of a certificate has to be able to prove they are who they say they are and they do this by holding certificates signed by a higher authority.

The Root Of The Matter

At the top of the chain is a root certificate: every operating system and browser comes pre-installed with a bunch of known root certificates, which are securely stored in what is called a “trust store”.

(It’s worth noting that the private keys for these certificates are very closely guarded by the issuing certificate authorities! A certificate is validated with a private key.)

Taking an example certificate that we have, which proves that our teamdf.cloud servers are in fact genuine teamdf.cloud servers, the chain of trust looks like this:

An Example Chain Of Trust

Middlepeople

In this case teamdf.cloud is validated by Sectigo Ltd, who are in turn validated by The USERTRUST Network certification authority, and the operating system or browser on your device has a root certificate for USERTRUST allowing everything to be proven.

An important thing to note here is that there may be more than one “middlepeople” in the scheme and therefore many intermediate certificates will exist in the chain. This tree structure means lots of companies can manage and issue certificates, spreading the burden and allowing different security services to be provided. 

It is common for an authoritiy to have multiple root certificates and to issue many intermediate certificates to other organisations.

What Could Go Wrong?

You may find that even though your certificate has just been purchased, those up the chain of trust have expired. This can cause quite a bit of confusion so it’s important to understand the above and have ways to rectify things.

This is exactly what happened recently with Sectigo’s AddTrust root certificate expiring (https://sectigo.com/resource-library/sectigos-addtrust-root-is-soon-to-expire-what-you-need-to-know)

A certificate authority, whether they are a root authority or an intermediate authority, has the ability to expire or revoke a certificate at any time. This can cause your certificate to become invalid and require a new set of intermediate certificates.

When you purchase your certificate you will be given details (links or downloads) for the intermediate certificate(s) as well. When you install the SSL certificate on FileMaker Server you will need to include these intermediate certificates (if more than one certificate is required you’ll need to combine them into a single file for upload).

FileMaker Server Import Certificate Dialog

When you have installed your certificate on FileMaker Server, connecting via FileMaker Pro, WebDirect, Data API or the admin console, the certificate will be verified by looking up the chain and verifying all the certificates it encounters right back to the root certificate at the top.

If you haven’t installed the intermediate certificate correctly or the chain is broken (e.g. an expired certificate), you will get an error. You can verify a certificate by clicking on the lock in the address bar of your browser or in a FileMaker Pro window.

Safari window highlighting the SSL lock icon

FileMaker Pro window highlighting SSL lock icon

Certificate Window

Trouble Shooting

So if things aren't working correctly some of the things to look into are:

• Check that all the certificates have been installed correctly
• Make sure you purchased your certificates from an authorised CA*
• Double check that the server itself has been setup correctly
• Use openssl to verify the certificates chain of trust, eg.

openssl verify -purpose sslserver -CAfile intermediateCertificate.crt certificate.crt

* CA = Certificate Authority

With SSL certificates now required on all FileMaker server installations, there are going to be some catches along the way. The above outlines things in a relatively simple form, but if you do strike issues, post a message below and we'll see if we can help resolve them.