Documentation Index
Fetch the complete documentation index at: https://private-7c7dfe99-page-updates.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Configuring automatic TLS provisioning via ACME
This page isn’t applicable to ClickHouse Cloud. The procedure documented here is automated in ClickHouse Cloud services.
Overview
ACME protocol defines automatic certificate update process with services like Let’s Encrypt or ZeroSSL. In short, ClickHouse as certificate requester needs to confirm domain ownership via predefined challenge types in order to get a certificate. To enable ACME, configure HTTP and HTTPS ports along with theacme block:
HTTP-01 challenge (more on challenge types here) requests during domain validation. Once validation completes and a certificate is issued, the HTTPS port serves encrypted traffic using the obtained certificate.
The HTTP port doesn’t need to be 80 on the server itself; it may be remapped using nftables or similar tools. Check your ACME provider’s documentation for accepted ports for HTTP-01 challenges.
In the acme block, we’re defining email for account creation, and accepting ACME service terms of service.
After that, the only thing we need is a list of domains.
Current limitations
- Only
HTTP-01challenge type is supported. - Only
RSA 2048keys are supported. - Rate limiting isn’t handled.
Configuration parameters
Configuration options available inacme section:
| Parameter | Default value | Description |
|---|---|---|
zookeeper_path | /clickhouse/acme | ZooKeeper path used to store ACME account data, certificates, and coordination state between ClickHouse nodes. |
directory_url | https://acme-v02.api.letsencrypt.org/directory | ACME directory endpoint used for certificate issuance. Defaults to the Let’s Encrypt production server. |
email | Email address used to create and manage the ACME account. ACME providers may use it for expiration notices and important updates. | |
terms_of_service_agreed | false | Indicates whether the ACME provider’s Terms of Service are accepted. Must be set to true to enable ACME. |
domains | List of domain names for which TLS certificates should be issued. Each domain is specified as a <domain> entry. | |
refresh_certificates_before | 2592000 (one month, in seconds) | Time before certificate expiration when ClickHouse will attempt to renew the certificate. |
refresh_certificates_task_interval | 3600 (one hour, in seconds) | Interval at which ClickHouse checks whether certificates need renewal. |
Administration
Initial deployment
When enabling the ACME client on a cluster with multiple replicas, additional care is required during the initial certificate issuance. The first replica that starts with ACME enabled will immediately attempt to create an ACME order and perform HTTP-01 challenge validation. If only a subset of replicas is serving traffic at that moment, the challenge is likely to fail, as other replicas won’t be able to respond to validation requests. If possible, it is recommended to temporarily route traffic to a single replica (for example, by adjusting DNS records) and allow it to complete the initial certificate issuance. Once the certificate is successfully issued and stored in Keeper, ACME can be enabled on the remaining replicas. They will automatically reuse the existing certificate and participate in future renewals. If routing traffic to a single replica isn’t feasible, an alternative approach is to manually upload the existing certificate and private key into Keeper before enabling the ACME client. This avoids the initial validation step and allows all replicas to start with a valid certificate already present. After the initial certificate has been issued or imported, certificate renewal doesn’t require special handling, as all replicas will already be running the ACME client and sharing state through Keeper.Keeper data structure
Migrating from other ACME clients
It is possible to migrate current TLS certificate and key to Keeper for easier migration. At the moment, server supports onlyRSA 2048 keys.
Assuming we’re migrating from certbot and using /etc/letsencrypt/live directory, one may use the following set of commands: