You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an essential feature. All traffic should go thru TLS Strictly speaking (even while testing or development). TLS and mTLS is used nowadays mostly everywhere and private cloud is not an exception. Client in this way should
act accordingly and have all needed tools. JDK and 3rdpart clients have built-in support for TLS. However there is a problem with self-signed certificates that often used in tests and private cloud envs.
Here is a list of major use cases that should be verified:
Connection to a host over HTTPs when host has valid certificate
Connection to a host over HTTPs when host has self-signed certificate
Connection to a host that requires client certificate to identify a client
Settings
Next settings should be deprecated:
com.clickhouse.client.config.ClickHouseClientOption#SSL "Whether to enable SSL/TLS for the connection." - SSL connections should be enabled by default. It means that no additional configuration needed to connect to host with valid not self-signed certificate.
com.clickhouse.client.config.ClickHouseClientOption#SSL_MODE "verify or not certificate: none (don't verify), strict (verify)" - this should be renamed to something more clear. But in general verification MUST be always one. There is a trust store that should be used instead.
com.clickhouse.client.config.ClickHouseClientOption#SSL_ROOT_CERTIFICATE "SSL/TLS root certificates." - Currently it means trusted root certificate and it should be named accordingly.
SSL_CERTIFICATE "SSL/TLS certificate." - Currently it means client certificate and it should be named accordingly.
SSL_KEY - "RSA key in PKCS#8 format." - Currently it means client private key and it should be named accordingly
KEY_STORE_TYPE "Specifies the type or format of the keystore/truststore file used for SSL/TLS configuration, such as "JKS" (Java KeyStore) or "PKCS12."" - should be derived from keystore/truststore configuration
TRUST_STORE "Path to the truststore file" - Currently is SSL trust store for http connection and it should be named accordingly
KEY_STORE_PASSWORD "Password needed to access the keystore file specified in the keystore config" - Currently it is a keystore password for SSL connections
Summary:
There is a trust store that can be defined by single file with correct extension corresponding to its type
trust store can be protected by a password
There is a key store that can be defined by a single file
key store can be protected by a password
Client would have one certificate/key to access password
Key rotation would require client to be restarted. (TBD: Need to discuss)
HTTPs Support
This is an essential feature. All traffic should go thru TLS Strictly speaking (even while testing or development). TLS and mTLS is used nowadays mostly everywhere and private cloud is not an exception. Client in this way should
act accordingly and have all needed tools. JDK and 3rdpart clients have built-in support for TLS. However there is a problem with self-signed certificates that often used in tests and private cloud envs.
Here is a list of major use cases that should be verified:
Settings
Next settings should be deprecated:
Summary:
Note 1: mTLS https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/
Note 2: certificate authentication with DB https://clickhouse.com/docs/en/guides/sre/ssl-user-auth
Metrics
Not yet
The text was updated successfully, but these errors were encountered: