TLS Authentication Methods

Authentication Methods

As well as simple key certificate pairs being used which requires the same key and certificate to be placed on all the instances in the HA pair or cluster. Certificate Authorities can also be used. When enabled the product uses peer-to-peer secure connections.

Without Certificate Authorities

When not using Certificate Authorities each instance in the system require the same key and certificate to be set. An example to create the key and self-signed certificate using openssl is:

        openssl genrsa -out ha_keydata 3072
        openssl req -new -x509 -key HA_key.pem -out HA_cert.pem -days 360
        

This will produce the key and certificate in the correct pem format. In this specific example the key will be between the lines:

-----BEGIN RSA PRIVATE KEY-----

And:

-----END RSA PRIVATE KEY-----

The certificate will be between:

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

If the key or certificate file does not contain a BEGIN and END, then it may have been created in the wrong format.

Once the key and certificate have been created, they can be copied into the correct location of each instance.

With Certificate Authorities

When using Certificate Authorities each instance requires a key and certificate to be set in the same way as without Certificate Authorities. However, as long as the credentials are created from an authorized system they do not have to be the same on each instance. To set the authorities the root and any intermediate certificates need to be provided.

An example to create a root certificate, an intermediate certificate, and two leaf certificates is:

        openssl genrsa -out root.key 2048
        openssl req -new -key root.key -out root.csr -config root_req.config
        openssl ca -in root.csr -out root.pem -config root.config -selfsign -extfile ca.ext -days 1095
        openssl genrsa -out intermediate.key 2048
        openssl req -new -key intermediate.key -out intermediate.csr -config intermediate_req.config
        openssl ca -in intermediate.csr -out intermediate.pem -config root.config -extfile ca.ext -days 730
        openssl genrsa -out leaf.key 2048
        openssl req -new -key leaf.key -out leaf.csr -config leaf_req.config
        openssl ca -in leaf.csr -out leaf.pem -config intermediate.config -days 365 -batch
        openssl genrsa -out leaf2.key 2048
        openssl req -new -key leaf2.key -out leaf2.csr -config leaf_req.config
        openssl ca -in leaf2.csr -out leaf2.pem -config intermediate.config -days 365 -batch
        

The files produced by this sequence that are required for authentication are:

root.pem

the root certificate

Intermediate.pem

the intermediate certificate

leaf.key

the key that will be used on the first instance

leaf.pem

the certificate that will be used on the first instance

leaf2.key

the key that will be used on the second instance

leaf2.pem

the certificate that will be used on the second instance

(All files will be in pem format)

For High Availability Pairing The leaf files need to be placed in the keystore of the corresponding instance and renamed to HA_key.pem and HA_cert.pem. For Clustering the leaf files need to be placed in the keystore of the corresponding instance and renamed to Cluster_key.pem and Cluster_cert.pem. To provide the Certificate Authorities a CAFile must be constructed from the root certificate and intermediate certificate and placed in the truststore in a file called HA_cafile.pem or Cluster_cafile.pem this can be done via:

        cat root.pem > HA_cafile.pem
        cat intermediate.pem >> HA_cafile.pem
        

When an instance’s certificate expires a new key and certificate can be created (using the intermediate credentials) and uploaded to the instance and once that instance has been restarted the instance will be authenticated without having to change the other instances.

If using High Availability Pairing and Clustering then it is possible to use file links to have the same credentials used for both systems eg:

        ln /var/messagesight/data/certificates/keystore/HA_cert.pem     /var/messagesight/data/certificates/keystore/Cluster_cert.pem
        ln /var/messagesight/data/certificates/keystore/HA_key.pem      /var/messagesight/data/certificates/keystore/Cluster_key.pem
        ln /var/messagesight/data/certificates/truststore/HA_cafile.pem /var/messagesight/data/certificates/truststore/Cluster_cert.pem
        

Certification Revocation List

If a certificate has become compromised prior to its expiration date then it can be added to a Certification Revocation List (CRL). The product supports a single consolidated CRL file in pem format for each connection.

The CRL file for High Availability pairing must be:

The CRL file for Clustering must be: