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 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.
Prerequisites
- 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.
In the next step, a CA-issued root certificate ca_cert.crt is appended to the file.
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.
Example:
|
Driver connection string |
Include in server certificate |
|---|---|
|
|
|
|
|
|
|
|
or
|
|
|
exa-prod.mydomain
or
|
Upload certificate chain and private key
-
Connect to EXAClusterOS (COS) on the cluster using
c4 connect -t <DEPLOYMENT>[.<NODE>]/cos. For example:If you do not specify a node, c4 will connect to the first active node in the deployment.
For more information about how to use
c4 connect, see How to use c4. -
To upload the certificate chain and the private key, use the ConfD command cert_update.
This procedure is carried out using ConfD.
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.
Restarting the cluster requires a short downtime.
Fingerprint
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.
