Upload TLS Certificate

This section explains how to create a TLS certificate chain and upload it to your Exasol system.

Certificate chain

Transport Layer Security (TLS) is a cryptographic protocol that uses digital certificate chains to enable secure communication between client and server. A certificate chain consists of multiple, related certificates that are linked together using digital signatures. Each certificate in the chain is digitally signed by the previous certificate in the chain. The root certificate in the chain can be self-signed or issued by a trusted Certificate Authority (CA). The certificate chain can contain any number of intermediate certificates between the root and server certificates.

TLS certificates are used to encrypt communication between an Exasol system and the different administration tools, for accessing the database from a database client, and for accessing BucketFS. You can upload the certificate chain to the Exasol system using ConfD.

If you need help on how to generate or use TLS certificates, contact your system administrator.


  • A self-signed or CA-signed server certificate using either RSA or ECC encryption algorithms
  • The root certificate and any intermediate certificates that are part of the certificate chain

  • A private key file for the server certificate

The maximum length of the private key is 8192 bits.

The private key for the server certificate must not be encrypted with a password.

Create a certificate chain

A certificate chain is a simple text file that contains all the certificates. The ordering of the certificates in the file is important. Certificate chains begin with the server certificate and end with the root certificate. In the following example we create a certificate chain file that contains two certificates.

In the first step, the server certificate server_cert.crt is copied to a new certificate chain file cert_chain.pem.

cat server_cert.crt > cert_chain.pem;

In the next step, a CA-issued root certificate ca_cert.crt is appended to the file.

cat ca_cert.crt >> cert_chain.pem

Use >> (append) in the second step, not > (overwrite).

The file cert_chain.pem now contains a certificate chain with a server certificate and a root certificate. The next step is to upload this file to the Exasol system together with the private key for the server certificate.

Hostnames in server certificate

If the SQL driver is using a connection string in the format first_host..last_host:port, the exact hostnames provided in the connection string must be included in the Common Name (CN) or Subject Alternative Name (SAN) of the server certificate.


Driver connection string

Include in server certificate (IP address range), (list of IP addresses)

db-node1..3.mydomain (DNS name range)






exa-prod.mydomain (hostname or DNS record that resolves to multiple IP addresses)




Upload certificate chain and private key

This procedure is carried out using ConfD.

  1. Connect to EXAClusterOS (COS) using c4 connect -t <DEPLOYMENT>[.<NODE>]/cos. For example:

    c4 connect -t 1/cos

    In most cases it does not matter on which node you access ConfD. If you do not specify a node, c4 will connect to the first active node in the deployment. The command prompt in COS indicates which node you are connected to:

    [root@n11 ~]#

    For more information about how to use c4 connect, see How to use c4.

  2. To upload the certificate chain and the private key, use the ConfD command cert_update.

    confd_client cert_update cert: '"{< ./cert_chain.pem}"' key: '"{< ./key.pem}"'

You must upload the entire TLS certificate chain, not just the server certificate.

You can only have one TLS certificate active at a time. Uploading a new certificate overwrites a previous TLS certificate. It is not possible to delete a certificate without replacing it.

Enable a TLS certificate

All Exasol drivers use TLS as the default cryptographic protocol for all connections. By default, each Exasol database uses a self-signed certificate for TLS encryption. If your database uses the default certificate or another self-signed certificate, you may need to update your connection strings to connect to the database.

SQL connections that are established after a new certificate and key have been uploaded will use the new files for authentication. A database restart is not required unless the database has been configured to use non-default paths for certificates and keys, or if the legacy TLS library has been enabled (by setting the respective database parameters). In that case, you must restart the database after uploading the files.

To enable BucketFS to pick up a new TLS certificate, you must restart the cluster after uploading the certificate. Before you restart the cluster, you must stop the database. For more information, see Stop and Start Nodes.

Restarting the cluster requires a short downtime.


You can use TLS fingerprints for clients that do not support certificate verification.

When you upload a new TLS certificate and restart the database a new fingerprint is generated, which means that you must update the connection string for all incoming connections. Connection requests with invalid fingerprints are rejected.