Upload TLS Certificate

Transport Layer Security (TLS) is a cryptographic protocol that enables secure communication between client and server. If you have your own self-signed or a Certificate Authority (CA)-signed TLS certificate for enhanced security, you can upload it through EXAoperation or XML-RPC. TLS certificates are used to encrypt communication (using the TLS 1.2 protocol) between the local client and EXAoperation and between database clients and the database.

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.

This section explains how to upload a TLS certificate in EXAoperation for both of these scenarios.

Prerequisites

  • A self-signed or CA-signed TLS certificate using either RSA or ECC encryption algorithms: 
    • If you are using RSA with a version of Exasol earlier than 7.1.2, the maximum key length is 2048 bits. With Exasol 7.1.2 or later, the maximum key length is 8192 bits.
    • If you are using a CA-signed certificate, correct host names are required in it.
  • Private key file for the certificate.

      The private key must not be encrypted with a password.

Upload TLS Certificate

In EXAoperation

Do the following to upload the certificate:

  1. Log in to EXAoperation as an admin.
  2. Click the TLS Certificate tab under Configuration > Access Management.
  3. Upload the certificate file and the private key file.
  4. Click Upload Key button.
  5. Go to ServicesEXAoperation and click the Restart button to restart EXAoperation. Restarting EXAoperation does not impact the database's availability.
    After restarting, EXAoperation uses an encrypted TLS connection.

If you upload a TLS certificate, the database automatically uses the same certificate for TLS connections between the database and other clients after a database restart. See Enable TLS Certificate for more information.

Through XML-RPC

  1. Run the following commands to import the XML-RPC packages:
  2. from xmlrpc.client import ServerProxy
    from xmlrpc.client import ServerProxy as xmlrpc

  3. Run the following command to create a connection with your Exasol cluster:
  4. import ssl
    server = ServerProxy ('https://user:password@<IP_Address>/cluster1', context=ssl._create_unverified_context (), allow_none = True)

  5. Run the following command to upload a TLS certificate and private key. Replace the absolute paths and file names with your own.
  6. cert = open('/absolute/path/to/certificate.pem', 'r').read()
    key = open('/absolute/path/to/key.pem', 'r').read()

    server.uploadTlsFiles(cert,key)

  7. Restart EXAoperation. Restarting EXAoperation does not impact the database's availability.
  8. server.restartEXAoperation('<node>')

    After restarting, EXAoperation uses an encrypted TLS connection.

If you upload a TLS certificate, the database automatically uses the same certificate for TLS connections between the database and other clients after a database restart. See Enable TLS Certificate for more information.

Enable TLS Certificate

All Exasol 7.1 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. For more details, see Exasol 7.1 Connection Security Changes.

To use the same TLS certificate that you uploaded to EXAoperation for communication between database clients and the database, do the following:

Restarting the database requires a short downtime.

Exasol automatically adds the certificate fingerprint to the database connection string in EXAoperation. This provides you an option to use fingerprints for the clients where certificate verification is not possible.

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.