TLS Encryption

Transport Layer Security (TLS) encryption is available on all supported network interfaces and protocols:

It's possible to configure encryption on all interfaces at once or individually.

QuestDB supports TLS v1.2 and v1.3.


TLS encryption is available to QuestDB Cloud and QuestDB Enterprise.

Enabling TLS

To enable TLS on all interfaces, set the following configuration configuration options:


The certificate .pem file should contain a DER-encoded server certificate. The file must include the full certificate chain, which consists of the server's own certificate followed by any intermediate certificates necessary to establish a trust path to a trusted root certificate.


encoded server cert
encoded intermediate cert

The private key file must contain the key in one of the following formats:

  • A DER-encoded plaintext RSA private key; as specified in PKCS#1/RFC3447
  • A DER-encoded plaintext private key; as specified in PKCS#8/RFC5958
  • A SEC1-encoded plaintext private key; as specified in RFC5915

If you need to create a quick .pem file for testing, see the below steps.

Enabling TLS for InfluxDB Line Protocol

To enable TLS for InfluxDB Line Protocol, apply the following configuration:


Enabling TLS for PGWire

To enable TLS for PGWire protocol, apply the following configuration:


Enabling TLS for HTTP server (REST API)

To enable TLS for the REST API, apply the following configuration:


Enabling TLS for minimal HTTP server

To enable TLS for the minimal HTTP server, apply the following configuration:


Rotating certificate and key

In case if you want to rotate the certificate and the private key periodically, QuestDB supports hot reload for the TLS files. To do that, first you need to replace the certificate and key files on disk with the new ones. Next, you need to call the reload_tls() SQL function like the following:

SELECT reload_tls();

The function returns true if the reload is successful; otherwise, it returns false. In case of unsuccessful reload, you should check error messages in the server logs for more details.

When Role-based Access Control (RBAC) is enabled, the reload_tls() SQL function is only available to the admin user, i.e. to the built-in user account configured with the acl.admin.user.enabled property.

Demo certificates

The QuestDB server can generate a demo certificate and private key for testing purposes upon startup. This feature is useful for quickly testing TLS connections without the need to manually create a certificate and private key.

To enable this feature, set the following configuration options in server.conf:


This method is suitable for testing purposes only and should never be used in a production environment.

The certificate and private key are generated when the server starts and are stored on disk in the $dbroot/conf directory. It is not possible to customize the generated demo certificate in any way.

The certificate is self-signed and is not recognized as trusted by any certificate authority.

Generating a test .pem certificate manually


Remember to use securely crafted certificates for production cases.

There are many ways that a valid .pem certificate can be created.

For a quick .pem certificate to use for testing, conduct the following steps.

  1. Create a .csr and .key file:
openssl req -new -newkey rsa:4096 -nodes -keyout questdb_test.key -out questdb_test.csr
  1. Combine the .csr and .key files into a new .pem file:
openssl x509 -req -sha256 -days 365 -in questdb_test.csr -signkey questdb_test.key -out questdb_test.pem

Finally, you can configure QuestDB server to use the newly generated certificate and key, e.g. with the following configuration: