Saltar al contenido principal
Esta página no se aplica a ClickHouse Cloud. El procedimiento que se documenta aquí está automatizado en los servicios de ClickHouse Cloud.
Esta guía ofrece una configuración sencilla y mínima para que ClickHouse use certificados OpenSSL para validar conexiones. Para esta demostración, se crean un certificado y una clave de una autoridad de certificación (CA) autofirmada, junto con certificados de nodo, a fin de establecer las conexiones con la configuración adecuada.
La implementación de TLS es compleja y hay muchas opciones que se deben tener en cuenta para garantizar una implementación totalmente segura y robusta. Este es un tutorial básico con ejemplos de configuración básica de TLS. Consulte con su equipo de PKI/seguridad para generar los certificados adecuados para su organización.Revise este tutorial básico sobre el uso de certificados para obtener una introducción general.
1

Crear una implementación de ClickHouse

Esta guía se redactó con Ubuntu 20.04 y con ClickHouse instalado en los siguientes hosts mediante el paquete DEB (con apt). El dominio es marsnet.local:
HostDirección IP
chnode1192.168.1.221
chnode2192.168.1.222
chnode3192.168.1.223
Consulta la Quick Start para obtener más información sobre cómo instalar ClickHouse.
2

Crear certificados TLS

El uso de certificados autofirmados es solo con fines de demostración y no debería usarse en producción. Las solicitudes de certificados deben crearse para que las firme la organización y validarse mediante la cadena de la CA que se configurará en la configuración. No obstante, estos pasos pueden usarse para configurar y probar la configuración, y luego reemplazarse por los certificados reales que se vayan a utilizar.
  1. Genere una clave que se utilizará para la nueva CA:
    openssl genrsa -out marsnet_ca.key 2048
    
  2. Genere un nuevo certificado de CA autofirmado. Lo siguiente creará un nuevo certificado que se utilizará para firmar otros certificados con la clave de la CA:
    openssl req -x509 -subj "/CN=marsnet.local CA" -nodes -key marsnet_ca.key -days 1095 -out marsnet_ca.crt
    
Haga una copia de seguridad de la clave y del certificado de CA en una ubicación segura fuera del clúster. Después de generar los certificados de los nodos, la clave debe eliminarse de los nodos del clúster.
  1. Verifique el contenido del nuevo certificado de CA:
    openssl x509 -in marsnet_ca.crt -text
    
  2. Cree una solicitud de certificado (CSR) y genere una clave para cada nodo:
    openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode1" -addext "subjectAltName = DNS:chnode1.marsnet.local,IP:192.168.1.221" -keyout chnode1.key -out chnode1.csr
    openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode2" -addext "subjectAltName = DNS:chnode2.marsnet.local,IP:192.168.1.222" -keyout chnode2.key -out chnode2.csr
    openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode3" -addext "subjectAltName = DNS:chnode3.marsnet.local,IP:192.168.1.223" -keyout chnode3.key -out chnode3.csr
    
  3. Con la CSR y la CA, cree nuevos pares de certificado y clave:
    openssl x509 -req -in chnode1.csr -out chnode1.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365 -copy_extensions copy
    openssl x509 -req -in chnode2.csr -out chnode2.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365 -copy_extensions copy
    openssl x509 -req -in chnode3.csr -out chnode3.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365 -copy_extensions copy
    
  4. Verifique en los certificados los campos subject e issuer:
    openssl x509 -in chnode1.crt -text -noout
    
  5. Compruebe que los nuevos certificados se validan con el certificado de la CA:
    openssl verify -CAfile marsnet_ca.crt chnode1.crt
    chnode1.crt: OK
    
3

Cree y configure un directorio para almacenar certificados y claves.

Esto debe hacerse en cada nodo. Use los certificados y las claves apropiados en cada host.
  1. Cree una carpeta en un directorio accesible para ClickHouse en cada nodo. Recomendamos usar el directorio de configuración predeterminado (por ejemplo, /etc/clickhouse-server):
    mkdir /etc/clickhouse-server/certs
    
  2. Copie el certificado de la CA, el certificado del nodo y la clave correspondientes a cada nodo en el nuevo directorio certs.
  3. Actualice el propietario y los permisos para que ClickHouse pueda leer los certificados:
    chown clickhouse:clickhouse -R /etc/clickhouse-server/certs
    chmod 600 /etc/clickhouse-server/certs/*
    chmod 755 /etc/clickhouse-server/certs
    ll /etc/clickhouse-server/certs
    
    total 20
    drw-r--r-- 2 clickhouse clickhouse 4096 Apr 12 20:23 ./
    drwx------ 5 clickhouse clickhouse 4096 Apr 12 20:23 ../
    -rw------- 1 clickhouse clickhouse  997 Apr 12 20:22 chnode1.crt
    -rw------- 1 clickhouse clickhouse 1708 Apr 12 20:22 chnode1.key
    -rw------- 1 clickhouse clickhouse 1131 Apr 12 20:23 marsnet_ca.crt
    
4

Configurar el entorno con clústeres básicos mediante ClickHouse Keeper

Para este entorno de implementación, se utilizan las siguientes configuraciones de ClickHouse Keeper en cada nodo. Cada servidor tendrá su propio <server_id>. (Por ejemplo, <server_id>1</server_id> para el nodo chnode1, y así sucesivamente.)
El puerto recomendado para ClickHouse Keeper es 9281. Sin embargo, el puerto es configurable y puede establecerse otro si este ya está en uso por otra aplicación en el entorno.Para obtener una explicación completa de todas las opciones, visita https://clickhouse.com/docs/operations/clickhouse-keeper/
  1. Añada lo siguiente dentro de la etiqueta <clickhouse> del config.xml del servidor ClickHouse
Para entornos de producción, se recomienda utilizar un archivo de configuración .xml independiente en el directorio config.d. Para más información, visite https://clickhouse.com/docs/operations/configuration-files/
<keeper_server>
    <tcp_port_secure>9281</tcp_port_secure>
    <server_id>1</server_id>
    <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
    <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>

    <coordination_settings>
        <operation_timeout_ms>10000</operation_timeout_ms>
        <session_timeout_ms>30000</session_timeout_ms>
        <raft_logs_level>trace</raft_logs_level>
    </coordination_settings>

    <raft_configuration>
        <secure>true</secure>
        <server>
            <id>1</id>
            <hostname>chnode1.marsnet.local</hostname>
            <port>9444</port>
        </server>
        <server>
            <id>2</id>
            <hostname>chnode2.marsnet.local</hostname>
            <port>9444</port>
        </server>
        <server>
            <id>3</id>
            <hostname>chnode3.marsnet.local</hostname>
            <port>9444</port>
        </server>
    </raft_configuration>
</keeper_server>
Cuando ClickHouse Keeper está integrado en ClickHouse server (como se muestra arriba), Keeper usa la configuración de OpenSSL del servidor definida en la sección OpenSSL de Configurar interfaces TLS en nodos de ClickHouse. Si ejecuta ClickHouse Keeper como un proceso independiente, debe añadir una sección <openSSL> al archivo de configuración de Keeper con el mismo certificado de la CA y la misma configuración del certificado y la clave del nodo. Consulte Configurar OpenSSL para ClickHouse Keeper independiente a continuación para obtener más información.
  1. Descomente y actualice la configuración de Keeper en todos los nodos, y establezca el indicador <secure> en 1:
    <zookeeper>
        <node>
            <host>chnode1.marsnet.local</host>
            <port>9281</port>
            <secure>1</secure>
        </node>
        <node>
            <host>chnode2.marsnet.local</host>
            <port>9281</port>
            <secure>1</secure>
        </node>
        <node>
            <host>chnode3.marsnet.local</host>
            <port>9281</port>
            <secure>1</secure>
        </node>
    </zookeeper>
    
  2. Actualice y añada la siguiente configuración del clúster en chnode1 y chnode2. chnode3 se usará para el quórum de ClickHouse Keeper.
Para esta configuración, solo hay configurado un clúster de ejemplo. Los clústeres de prueba de ejemplo deben eliminarse, comentarse o, si existe un clúster en pruebas, se debe actualizar el puerto y añadir la opción <secure>. Deben establecerse <user y <password> si el usuario default se configuró inicialmente con una contraseña durante la instalación o en el archivo users.xml.
A continuación se crea un clúster con una réplica de segmento en dos servidores (uno en cada nodo).
<remote_servers>
    <cluster_1S_2R>
        <shard>
            <replica>
                <host>chnode1.marsnet.local</host>
                <port>9440</port>
                <user>default</user>
                <password>ClickHouse123!</password>
                <secure>1</secure>
            </replica>
            <replica>
                <host>chnode2.marsnet.local</host>
                <port>9440</port>
                <user>default</user>
                <password>ClickHouse123!</password>
                <secure>1</secure>
            </replica>
        </shard>
    </cluster_1S_2R>
</remote_servers>
  1. Defina los valores de las macros para poder crear una tabla ReplicatedMergeTree de prueba. En chnode1:
    <macros>
        <shard>1</shard>
        <replica>replica_1</replica>
    </macros>
    
    En chnode2:
    <macros>
        <shard>1</shard>
        <replica>replica_2</replica>
    </macros>
    
5

Configurar interfaces TLS en nodos de ClickHouse

Los ajustes que aparecen a continuación se configuran en el config.xml del servidor ClickHouse
  1. Establezca el nombre para mostrar de la implementación (opcional):
    <display_name>clickhouse</display_name>
    
  2. Configure ClickHouse para que escuche en puertos externos:
    <listen_host>0.0.0.0</listen_host>
    
  3. Configure el puerto https y deshabilite el puerto http en cada nodo:
    <https_port>8443</https_port>
    {/*<http_port>8123</http_port>*/}
    
  4. Configure el puerto TCP seguro nativo de ClickHouse y deshabilite el puerto no seguro predeterminado en cada nodo:
    <tcp_port_secure>9440</tcp_port_secure>
    {/*<tcp_port>9000</tcp_port>*/}
    
  5. Configure el puerto interserver https y deshabilite el puerto no seguro predeterminado en cada nodo:
    <interserver_https_port>9010</interserver_https_port>
    {/*<interserver_http_port>9009</interserver_http_port>*/}
    
  6. Configure OpenSSL con certificados y rutas
Cada nombre de archivo y ruta debe actualizarse para que coincida con el nodo en el que se está realizando la configuración. Por ejemplo, actualice la entrada <certificateFile> para que sea chnode2.crt al configurar el host chnode2.
<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-server/certs/chnode1.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-server/certs/chnode1.key</privateKeyFile>
        <verificationMode>relaxed</verificationMode>
        <caConfig>/etc/clickhouse-server/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <caConfig>/etc/clickhouse-server/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>relaxed</verificationMode>
        <invalidCertificateHandler>
            <name>RejectCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>
Para obtener más información, visita esta página
  1. Configura TLS para gRPC en cada nodo:
    <grpc>
        <enable_ssl>1</enable_ssl>
        <ssl_cert_file>/etc/clickhouse-server/certs/chnode1.crt</ssl_cert_file>
        <ssl_key_file>/etc/clickhouse-server/certs/chnode1.key</ssl_key_file>
        <ssl_require_client_auth>true</ssl_require_client_auth>
        <ssl_ca_cert_file>/etc/clickhouse-server/certs/marsnet_ca.crt</ssl_ca_cert_file>
        <transport_compression_type>none</transport_compression_type>
        <transport_compression_level>0</transport_compression_level>
        <max_send_message_size>-1</max_send_message_size>
        <max_receive_message_size>-1</max_receive_message_size>
        <verbose_logs>false</verbose_logs>
    </grpc>
    
    Para obtener más información, visita https://clickhouse.com/docs/interfaces/grpc/
  2. Configura ClickHouse client en al menos uno de los nodos para que use TLS en las conexiones en su propio archivo config.xml (de forma predeterminada, en /etc/clickhouse-client/):
    <openSSL>
        <client>
            <loadDefaultCAFile>false</loadDefaultCAFile>
            <caConfig>/etc/clickhouse-server/certs/marsnet_ca.crt</caConfig>
            <cacheSessions>true</cacheSessions>
            <disableProtocols>sslv2,sslv3</disableProtocols>
            <preferServerCiphers>true</preferServerCiphers>
            <invalidCertificateHandler>
                <name>RejectCertificateHandler</name>
            </invalidCertificateHandler>
        </client>
    </openSSL>
    
  3. Deshabilita los puertos de emulación predeterminados para MySQL y PostgreSQL:
    {/*mysql_port>9004</mysql_port*/}
    {/*postgresql_port>9005</postgresql_port*/}
    
6

Pruebas

  1. Inicie todos los nodos, uno por uno:
    service clickhouse-server start
    
  2. Verifique que los puertos seguros estén activos y en escucha; debería verse similar a este ejemplo en cada nodo:
    root@chnode1:/etc/clickhouse-server# netstat -ano | grep tcp
    
    tcp        0      0 0.0.0.0:9010            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:9440            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:9281            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 192.168.1.221:33046     192.168.1.222:9444      ESTABLISHED off (0.00/0/0)
    tcp        0      0 192.168.1.221:42730     192.168.1.223:9444      ESTABLISHED off (0.00/0/0)
    tcp        0      0 192.168.1.221:51952     192.168.1.222:9281      ESTABLISHED off (0.00/0/0)
    tcp        0      0 192.168.1.221:22        192.168.1.210:49801     ESTABLISHED keepalive (6618.05/0/0)
    tcp        0     64 192.168.1.221:22        192.168.1.210:59195     ESTABLISHED on (0.24/0/0)
    tcp6       0      0 :::22                   :::*                    LISTEN      off (0.00/0/0)
    tcp6       0      0 :::9444                 :::*                    LISTEN      off (0.00/0/0)
    tcp6       0      0 192.168.1.221:9444      192.168.1.222:59046     ESTABLISHED off (0.00/0/0)
    tcp6       0      0 192.168.1.221:9444      192.168.1.223:41976     ESTABLISHED off (0.00/0/0)
    
    Puerto de ClickHouseDescripción
    8443interfaz HTTPS
    9010puerto HTTPS entre servidores
    9281puerto seguro de ClickHouse Keeper
    9440protocolo TCP Native seguro
    9444puerto Raft de ClickHouse Keeper
  3. Verifique el estado de ClickHouse Keeper Los comandos típicos de 4 letter word (4lW) no funcionarán con echo sin TLS. A continuación se explica cómo usar estos comandos con openssl.
    • Inicie una sesión interactiva con openssl
openssl s_client -connect chnode1.marsnet.local:9281
CONNECTED(00000003)
depth=0 CN = chnode1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = chnode1
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = chnode1
   i:CN = marsnet.local CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICtDCCAZwCFD321grxU3G5pf6hjitf2u7vkusYMA0GCSqGSIb3DQEBCwUAMBsx
...
  • En la sesión de OpenSSL, envíe los comandos 4LW
    mntr
    
    ---
    Post-Handshake New Session Ticket arrived:
    SSL-Session:
        Protocol  : TLSv1.3
    ...
    read R BLOCK
    zk_version      v22.7.3.5-stable-e140b8b5f3a5b660b6b576747063fd040f583cf3
    zk_avg_latency  0
    zk_max_latency  4087
    zk_min_latency  0
    zk_packets_received     4565774
    zk_packets_sent 4565773
    zk_num_alive_connections        2
    zk_outstanding_requests 0
    zk_server_state leader
    zk_znode_count  1087
    zk_watch_count  26
    zk_ephemerals_count     12
    zk_approximate_data_size        426062
    zk_key_arena_size       258048
    zk_latest_snapshot_size 0
    zk_open_file_descriptor_count   187
    zk_max_file_descriptor_count    18446744073709551615
    zk_followers    2
    zk_synced_followers     1
    closed
    
  1. Inicie el cliente de ClickHouse con la opción --secure y el puerto TLS:
    root@chnode1:/etc/clickhouse-server# clickhouse-client --user default --password ClickHouse123! --port 9440 --secure --host chnode1.marsnet.local
    ClickHouse client version 22.3.3.44 (official build).
    Connecting to chnode1.marsnet.local:9440 as user default.
    Connected to ClickHouse server version 22.3.3 revision 54455.
    
    clickhouse :)
    
  2. Inicie sesión en la UI de Play mediante la interfaz https en https://chnode1.marsnet.local:8443/play.
el navegador mostrará un certificado no confiable, ya que se accede a él desde una estación de trabajo y los certificados no están en los almacenes de CA raíz de la máquina cliente. Al usar certificados emitidos por una autoridad pública o una CA empresarial, debería aparecer como de confianza.
  1. Cree una tabla replicada:
    clickhouse :) CREATE TABLE repl_table ON CLUSTER cluster_1S_2R
                (
                    id UInt64,
                    column1 Date,
                    column2 String
                )
                ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/default/repl_table', '{replica}' )
                ORDER BY (id);
    
    ┌─host──────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
    │ chnode2.marsnet.local │ 9440 │      0 │       │                   1 │                0 │
    │ chnode1.marsnet.local │ 9440 │      0 │       │                   0 │                0 │
    └───────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘
    
  2. Añade un par de filas en chnode1:
    INSERT INTO repl_table
    (id, column1, column2)
    VALUES
    (1,'2022-04-01','abc'),
    (2,'2022-04-02','def');
    
  3. Verifique la replicación consultando las filas en chnode2:
    SELECT * FROM repl_table
    
    ┌─id─┬────column1─┬─column2─┐
    │  1 │ 2022-04-01 │ abc     │
    │  2 │ 2022-04-02 │ def     │
    └────┴────────────┴─────────┘
    

Configurar OpenSSL para ClickHouse Keeper en modo independiente

Al ejecutar ClickHouse Keeper como un proceso independiente (en lugar de estar integrado en ClickHouse server), los certificados y la configuración de OpenSSL deben configurarse por separado en el archivo de configuración de Keeper. De lo contrario, Keeper no podrá establecer conexiones seguras para la comunicación con el cliente (tcp_port_secure) ni para la replicación Raft entre nodos de Keeper. Agregue la siguiente sección <openSSL> al archivo de configuración de ClickHouse Keeper en modo independiente en cada nodo:
Cada nombre de archivo debe actualizarse para que coincida con el nodo en el que se está realizando la configuración. Por ejemplo, actualice la entrada <certificateFile> para que sea chnode2.crt al configurar el host chnode2.
<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-keeper/certs/chnode1.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-keeper/certs/chnode1.key</privateKeyFile>
        <verificationMode>relaxed</verificationMode>
        <caConfig>/etc/clickhouse-keeper/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <caConfig>/etc/clickhouse-keeper/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>relaxed</verificationMode>
        <invalidCertificateHandler>
            <name>RejectCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>
La sección <server> se utiliza para las conexiones entrantes de los clientes en el puerto seguro de Keeper (tcp_port_secure). La sección <client> se utiliza para las conexiones salientes entre nodos de Keeper durante la replicación de Raft.
Las rutas de los certificados indicadas arriba usan /etc/clickhouse-keeper/certs/, que es la ruta típica para instalaciones de Keeper en modo independiente. Si instaló Keeper en una ruta distinta, ajústela según corresponda. Los certificados en sí son los mismos que se crearon en el paso 2.

Modos de verificación de OpenSSL y manejadores de certificados

La configuración <openSSL> admite varias opciones para <verificationMode> y <invalidCertificateHandler> que controlan cómo ClickHouse valida los certificados TLS. Estos ajustes se aplican a clickhouse-server, clickhouse-client y ClickHouse Keeper en modo independiente.

Modos de verificación

Configure <verificationMode> en la sección <server> o <client> de <openSSL>:
ModoDescripción
noneSin verificación de certificados. La conexión está cifrada, pero no se comprueba la identidad del peer. Úselo solo para pruebas.
relaxedVerifica el certificado del peer si se presenta, pero no falla si no se proporciona ninguno.
onceEn el lado del servidor, verifica el certificado del cliente solo durante el handshake inicial y omite la renegociación. En el lado del cliente, se comporta igual que relaxed.
strictRequiere y verifica por completo el certificado del peer. La conexión falla si el certificado no está presente, ha caducado o no está firmado por una CA de confianza. Recomendado para producción.

Manejadores de certificados no válidos

Configura <invalidCertificateHandler> en la sección <server> o <client> de <openSSL>. Este manejador determina qué ocurre cuando falla la verificación del certificado. En el lado del servidor, controla la respuesta ante certificados de cliente no válidos. En el lado del cliente, controla la respuesta ante certificados de servidor no válidos.
ManejadorDescripción
RejectCertificateHandlerRechaza la conexión si el certificado no es válido. Esta es la configuración predeterminada y recomendada.
AcceptCertificateHandlerAcepta la conexión incluso si el certificado no es válido. Úsalo solo para pruebas.

Ejemplo: desactivar la verificación de certificados

Desactivar la verificación de certificados elimina las comprobaciones de identidad de TLS y expone las conexiones a ataques de tipo man-in-the-middle. Use esta configuración solo en entornos aislados de desarrollo o pruebas.
Para omitir por completo la verificación de certificados (por ejemplo, al usar certificados autofirmados en un entorno de pruebas), establezca verificationMode en none y use AcceptCertificateHandler. En clickhouse-client, también puede usar la opción de CLI --accept-invalid-certificate, que aplica ambos ajustes automáticamente. clickhouse-client (/etc/clickhouse-client/config.xml):
<openSSL>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>none</verificationMode>
        <invalidCertificateHandler>
            <name>AcceptCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>
clickhouse-server (config.xml o un archivo en config.d/). La sección <server> aún requiere las rutas al certificado y a la clave privada, porque el servidor debe presentar su propio certificado a los clientes, incluso cuando no verifica el de estos:
<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-server/certs/server.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-server/certs/server.key</privateKeyFile>
        <verificationMode>none</verificationMode>
        <caConfig>/etc/clickhouse-server/certs/ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>none</verificationMode>
        <invalidCertificateHandler>
            <name>AcceptCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>
ClickHouse Keeper independiente (archivo de configuración de Keeper):
<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-keeper/certs/keeper.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-keeper/certs/keeper.key</privateKeyFile>
        <verificationMode>none</verificationMode>
        <caConfig>/etc/clickhouse-keeper/certs/ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>none</verificationMode>
        <invalidCertificateHandler>
            <name>AcceptCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>

Resumen

Este artículo se ha centrado en configurar un entorno de ClickHouse con TLS. Los ajustes variarán según los requisitos de cada entorno de producción; por ejemplo, los niveles de verificación de certificados, los protocolos, los cifrados, etc. Pero ahora debería tener una buena comprensión de los pasos necesarios para configurar e implementar conexiones seguras.
Última modificación el 29 de junio de 2026