Upload TLS Certificate
This section explains how to create a TLS certificate chain and upload it to your Exasol system.
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 certificate chain can contain any number of intermediate certificates between the root and server certificates. The root certificate in the chain can be self-signed or issued by a trusted Certificate Authority (CA).
TLS certificates are used to encrypt communication with the administrative interfaces of an Exasol system and between database clients and the database. If you have a self-signed or Certificate Authority (CA)-signed TLS certificate, you can upload the certificate chain using ConfD.
If you are unsure about how to generate or use TLS certificates, contact your system administrator.
- A self-signed or CA-signed TLS 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
If you are using a CA-signed certificate, make sure that it contain the correct host names.
The maximum length of the private key is 8192 bits.
The private key must not be encrypted with a password.
root@<server>:~# mkdir /opt/cert
root@<server>:~# cd /opt/cert/
root@<server>:/opt/cert# openssl req -new -newkey rsa:2048 -x509 -sha256 -days 365 -nodes -out server_cert.crt -keyout key.pem
Generating a 2048 bit RSA private key
writing new private key to 'key.pem'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) :
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) :
Common Name (e.g. server FQDN or YOUR name) :
Email Address :
drwxr-xr-x 1 root root 4096 Aug 22 15:04 ./
drwxr-xr-x 1 root root 4096 Aug 22 15:04 ../
-rw-r--r-- 1 root root 1923 Aug 22 15:04 server_cert.crt
-rw------- 1 root root 3272 Aug 22 15:04 key.pem
Create Certificate Chain
A certificate chain is simply a text file containing all the certificates. However, the ordering of the certificates is important. Certificate chains begin with the server certificate and end with the highest level CA certificate.
In the following example there are just two certificates. The server certificate is first copied to a new certificate chain file, and then the CA certificate is appended to the file.
cert_chain.pem now contains the full certificate chain (two certificates) and can be uploaded to Exasol together with the private key for the server certificate.
Upload Certificate Chain and Private Key
You must upload the entire TLS certificate chain, not just the server certificate.
The following examples use the command-line tool confd_client in a Linux terminal connected to a database node. For more information about how to use this tool, see ConfD.
Placeholder values are indicated with UPPERCASE characters. Replace the placeholders with your own values.
To upload the certificate chain and the private key, use the ConfD command cert_update.
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.
To use the uploaded TLS certificate also for communication between database clients and the database, restart the database. For more information, see Start a Database.
Exasol automatically adds the certificate fingerprint to the database connection string. This provides you an option to use fingerprints for clients that do not support certificate verification. The fingerprint is updated when you upload a new TLS certificate and restart the database. In this case, you should update the connection string for all incoming connections. All connection requests with invalid fingerprints are rejected.