Enabling TLS for FTL Server

FTL supports two different mechanisms for enabling TLS at FTL server:

  • User-defined certificates, where administrators provide TLS certificates to FTL server (and possibly clients, for mTLS authentication). The administrator is responsible for choosing a certificate authority and obtaining the certificates. FTL server loads its certificate on startup.

  • FTL-generated certificates, where administrators run FTL tools to initialize TLS keys and trust roots for an FTL realm. At runtime, FTL server issues TLS certificates as needed.

FTL and eFTL components can use TLS 1.2 or TLS 1.3. TLS 1.3 is used wherever possible.

The openssl library is used for FTL transports between FTL components (on both client and server side). The openssl library is also used for the server side of any HTTPS and eFTL client connections accepted by FTL server.

Administrators may configure the openssl security level. In general, a higher security level requires stronger certificates and encryption. See FTL Server Configuration Parameters

Enabling TLS with User-defined Certificates

To enable TLS with user-defined certificates, specify the following parameters in the FTL server yaml configuration file:

  • tls.server.cert

  • tls.server.private.key

  • tls.server.private.key.password (if needed)

  • tls.client.trust.file (if needed)

For details, see FTL Server Configuration Parameters

On starting, FTL server loads the certificate and private key. The private key password is used to decrypt the private key. When making outgoing TLS connections to other FTL servers, FTL server verifies the remote server's certificate using the trust file, or the system trust store if no trust file is specified.

When clients and other FTL servers connect to an FTL server, they ensure that the hostname used to connect to FTL server matches the subject alternative name (SAN) in FTL server's certificate. The certificate must have a SAN. In the certificate's SAN, the leftmost component of a DNS name may be a wildcard.

Note: The certificate must look valid to both clients and FTL servers. If clients and servers use different hostnames to connect to FTL server, the certificate's SAN must contain multiple entries and/or a wildcard entry.

If you are terminating TLS at an ingress point for client connections, do not configure FTL server with a TLS certificate. This means that FTL server does not use TLS for communication with clients or other FTL servers.

Note: Secure peer-to-peer transports (used for direct communication between applications) are not permitted when user-defined certificates are configured. If applications must communicate directly (without FTL server in the middle),see Enabling TLS for FTL Server

 

 

See samples/yaml/tls-user for details on how to setup FTL Server with user-defined certificates.

Enabling TLS with FTL-Generated Certificates

Instead of taking a certificate from the user, FTL server can generate and manage TLS certificates. This is required in the following cases:

  • Applications communicate directly with each other, using secure peer-to-peer transports.

  • Applications communicate with each other via transport bridges, using secure transports

Before you begin

  • Choose a keystore file password, and determine the appropriate level of security for that password.

  • Ensure that the clocks on all servers in a cluster are synchronized.

  1. Remove any obsolete TLS data files from the FTL servers' data directories.

  2. Generate TLS data files.

    To generate full-security files, enter:

    tibftlserver --init-security file:<pw_file_name> -c <my_config_file_path> -n <svr_name>

    This command instructs the FTL server to generate new TLS data files, encrypting the new keystore file with the password.

    (If the FTL server detects existing TLS files, it does not generate them anew. However, the FTL server does not decrypt or inspect existing files.)The server generates TLS files in the data directory (specified in the configuration file). If the data directory is unavailable, the server writes these files to the current directory. After writing the files, the FTL server exits.

  3. Distribute the TLS files.The keystore file and trust file must be distributed to all FTL servers which include all core servers and auxiliary servers at all sites (including primary, satellite, and DR sites).Every server uses the same private key to identify itself. Every server uses the same trust file to verify the identity of FTL servers.

    • Supply copies of the keystore file and trust file to every FTL server. Place these files in the data directory of the servers.

      Note: Specify the data directory in the configuration file for each FTL server

    • Supply a copy of the trust file to every client including application programs and browsers that access the FTL server GUI.

    Note: When a server generates new TLS data files, you must redistribute these files.
Note: See the ftlstart script in the samples directory. The --secure option illustrates a basic way to start a secure FTL server.