Skip to content

Commit b47157d

Browse files
Merge remote-tracking branch 'origin/main' into locadex/parallel/t9n-main-mtlkv0dh97mm5xszdcmdetec
2 parents cca1caa + 4b75d0d commit b47157d

1 file changed

Lines changed: 103 additions & 0 deletions

File tree

docs/guides/sre/tls/configuring-tls.md

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -549,6 +549,109 @@ The `<server>` section is used for incoming client connections on the secure Kee
549549
The certificate paths above use `/etc/clickhouse-keeper/certs/` which is the typical path for standalone Keeper installations. If you installed Keeper using a different path, adjust accordingly. The certificates themselves are the same ones created in [step 2](#2-create-tls-certificates).
550550
:::
551551
552+
## OpenSSL verification modes and certificate handlers {#openssl-verification-modes}
553+
554+
The `<openSSL>` configuration supports several options for `<verificationMode>` and `<invalidCertificateHandler>` that control how ClickHouse validates TLS certificates. These settings apply to clickhouse-server, clickhouse-client, and standalone ClickHouse Keeper.
555+
556+
### Verification modes {#verification-modes}
557+
558+
Set `<verificationMode>` inside the `<server>` or `<client>` section of `<openSSL>`:
559+
560+
| Mode | Description |
561+
|------|-------------|
562+
| `none` | No certificate verification. The connection is encrypted but the peer's identity is not checked. Only use this for testing. |
563+
| `relaxed` | Verifies the peer certificate if one is presented, but does not fail if no certificate is provided. |
564+
| `once` | On the server side, verifies the client certificate on the initial handshake only and skips renegotiation. On the client side, behaves the same as `relaxed`. |
565+
| `strict` | Requires and fully verifies the peer certificate. The connection fails if the certificate is missing, expired, or not signed by a trusted CA. Recommended for production. |
566+
567+
### Invalid certificate handlers {#invalid-certificate-handlers}
568+
569+
Set `<invalidCertificateHandler>` inside the `<server>` or `<client>` section of `<openSSL>`. This handler determines what happens when certificate verification fails. On the server side, it controls the response to invalid client certificates. On the client side, it controls the response to invalid server certificates.
570+
571+
| Handler | Description |
572+
|---------|-------------|
573+
| `RejectCertificateHandler` | Rejects the connection if the certificate is invalid. This is the default and recommended setting. |
574+
| `AcceptCertificateHandler` | Accepts the connection even if the certificate is invalid. Only use this for testing. |
575+
576+
### Example: disabling certificate verification {#disabling-certificate-verification}
577+
578+
:::warning
579+
Disabling certificate verification removes TLS identity checks and exposes connections to man-in-the-middle attacks. Only use this configuration in isolated development or testing environments.
580+
:::
581+
582+
To skip certificate verification entirely (for example, when using self-signed certificates in a test environment), set `verificationMode` to `none` and use `AcceptCertificateHandler`.
583+
584+
For `clickhouse-client`, you can also use the `--accept-invalid-certificate` CLI flag, which applies both settings automatically.
585+
586+
**clickhouse-client** (`/etc/clickhouse-client/config.xml`):
587+
588+
```xml
589+
<openSSL>
590+
<client>
591+
<loadDefaultCAFile>false</loadDefaultCAFile>
592+
<cacheSessions>true</cacheSessions>
593+
<disableProtocols>sslv2,sslv3</disableProtocols>
594+
<preferServerCiphers>true</preferServerCiphers>
595+
<verificationMode>none</verificationMode>
596+
<invalidCertificateHandler>
597+
<name>AcceptCertificateHandler</name>
598+
</invalidCertificateHandler>
599+
</client>
600+
</openSSL>
601+
```
602+
603+
**clickhouse-server** (`config.xml` or a file in `config.d/`). The `<server>` section still requires certificate and key paths because the server must present its own certificate to clients, even when it isn't verifying theirs:
604+
605+
```xml
606+
<openSSL>
607+
<server>
608+
<certificateFile>/etc/clickhouse-server/certs/server.crt</certificateFile>
609+
<privateKeyFile>/etc/clickhouse-server/certs/server.key</privateKeyFile>
610+
<verificationMode>none</verificationMode>
611+
<caConfig>/etc/clickhouse-server/certs/ca.crt</caConfig>
612+
<cacheSessions>true</cacheSessions>
613+
<disableProtocols>sslv2,sslv3</disableProtocols>
614+
<preferServerCiphers>true</preferServerCiphers>
615+
</server>
616+
<client>
617+
<loadDefaultCAFile>false</loadDefaultCAFile>
618+
<cacheSessions>true</cacheSessions>
619+
<disableProtocols>sslv2,sslv3</disableProtocols>
620+
<preferServerCiphers>true</preferServerCiphers>
621+
<verificationMode>none</verificationMode>
622+
<invalidCertificateHandler>
623+
<name>AcceptCertificateHandler</name>
624+
</invalidCertificateHandler>
625+
</client>
626+
</openSSL>
627+
```
628+
629+
**Standalone ClickHouse Keeper** (Keeper configuration file):
630+
631+
```xml
632+
<openSSL>
633+
<server>
634+
<certificateFile>/etc/clickhouse-keeper/certs/keeper.crt</certificateFile>
635+
<privateKeyFile>/etc/clickhouse-keeper/certs/keeper.key</privateKeyFile>
636+
<verificationMode>none</verificationMode>
637+
<caConfig>/etc/clickhouse-keeper/certs/ca.crt</caConfig>
638+
<cacheSessions>true</cacheSessions>
639+
<disableProtocols>sslv2,sslv3</disableProtocols>
640+
<preferServerCiphers>true</preferServerCiphers>
641+
</server>
642+
<client>
643+
<loadDefaultCAFile>false</loadDefaultCAFile>
644+
<cacheSessions>true</cacheSessions>
645+
<disableProtocols>sslv2,sslv3</disableProtocols>
646+
<preferServerCiphers>true</preferServerCiphers>
647+
<verificationMode>none</verificationMode>
648+
<invalidCertificateHandler>
649+
<name>AcceptCertificateHandler</name>
650+
</invalidCertificateHandler>
651+
</client>
652+
</openSSL>
653+
```
654+
552655
## Summary {#summary}
553656
554657
This article focused on getting a ClickHouse environment configured with TLS. The settings will differ for different requirements in production environments; for example, certificate verification levels, protocols, ciphers, etc. But you should now have a good understanding of the steps involved in configuring and implementing secure connections.

0 commit comments

Comments
 (0)