Concepts

Concepts for certificate management

Abstract

This page describes FairCom's best practices for certificate management.

Use a private certificate authority to secure FairCom servers and clients

FairCom's servers and clients communicate over secure protocols including HTTPS, WebSocket Secure (WSS), and MQTT Secure (MQTTS). These protocols require clients and servers to use "signed certificates" that identify them as legitimate so that malicious users cannot impersonate them. The best practice for managing and obtaining these signed certificates is to use a "key pair" provided by a certificate authority (CA). The key pair is a private key file and a public certificate file.

You can establish your own private CA to provide a key pair to use when you create your signed server and client certificates. If your company has already set up a private CA, you can skip the "Create certificate authority" step of the tutorials. Contact your security team to obtain a key pair for each of your FairCom servers and for each of your clients. They should also provide you with a copy of your company's CA certificate.

Your private CA is used only inside your company. It is safe and appropriate for you to maintain your own private CA if you follow a few simple guidelines. In contrast, a public CA is used for servers that deliver content to the Internet. Because FairCom servers and clients are only used inside your company's internal network, they can use the certificate file from the key pair that you create for your private CA.

Input your private CA certificate into the key stores of sources such as operating systems, browsers, and programming languages. Once your CA certificate is trusted by these sources, any server or client certificates signed by that CA certificate will also be trusted by those sources.

Server and client certificates

A CA may issue certificates for clients and servers. All sources that trust the CA certificate then automatically trust these additional certificates.

Client certificate file

The client certificate file contains a client certificate with its associated public key and client private key. A CA administrator uses the private key password to encrypt the client private key.

A user configures client software to use the client certificate file instead of a username and password.

If the client private key in the PEM file is encrypted, the software must decrypt it before it can authenticate to the server. The user must embed the private key password in the software or supply it when logging in.

FairCom software determines a client certificate file is valid under the following conditions:

It must be a PEM file.
It must follow the X.509 standard.
It must have a complete certificate chain using the same root CA as the server certificate.
The current date must be between the X.509 Not Before and X.509 Not After fields.
The X.509 subject field must contain a valid username.

Advantages of client certificate files

Client certificates have the following advantages over usernames and passwords:

A client certificate file is more secure than a username because a certificate authority signs the username.
A client certificate is more secure than a password because its private key is the password. A private key cannot be brute forced because it is too long and crypto-random. In addition, client software never transmits the private key to the server; instead, the TLS handshake validates it.
You can store a client certificate in secure key stores provided by the operating system or certificate management software. File system permissions can also protect a certificate.
The organization must sign a client certificate. Malicious attackers cannot falsify a client certificate because they do not have the private CA key that signed it.
A client certificate with an encrypted private key provides multi-factor authentication because a client using the certificate must also provide the private key password to decrypt the private key.
An organization may optionally assign a client certificate's validity start and end dates to prevent the use of old credentials and the premature use of new credentials.
An organization may optionally embed specific IP Addresses or hostnames into a certificate to ensure the certificate is valid only when a client connects from one of those locations.
An organization can revoke a certificate to prevent it from being used.

Certificate manager Overview

The tutorials section uses Python scripts to make it easy to create and manage your private CA and associated server and client certificates. These scripts are located in the <faircomInstallationDirectory>/drivers/certificates folder.

You must install Python for tutorial scripts to run.

Use createcacert.py to create a CA key file and CA certificate file. These are self-signed files that form a CA key pair and are referred to as the root certificate. They are the most important parts of a private certificate authority.
Use createservercert.py to create a server key file and server certificate file for a specific server you want to secure. These two files are a server key pair and are known as leaf certificates.
Move the server leaf certificates to the server and configure the server to use services.json.
Use importcert.py to import the CA certificate (not the CA key) into the OS keystore for every computer that will connect to the server. This results in those computers trusting any certificate signed by the CA certificate. This eliminates the need for Google Chrome to display a warning that a server is not trusted.
Use createclientcert.py to create client keys and certificates, which are signed by the CA key. These typically work like a username and password
Note
NEW 2023-12-04 Client certificates can be created but can only be implemented with the FairCom ISAM interface.
FairCom will fully support client certificates in a future release.