[FR] SSL support
ralphM78 opened this issue · 9 comments
Hi,
would it be possible to add SSL support for querying clickhouse ?
Ralph
Hey. TBH, I don't see a reason for it. If you really need it, just put nginx/any other reversed proxy in front of it.
In our case, GCH is placed behind the carbonapi on the same host, so it uses localhost.
For sure there are many ways. But it would be easier in some cases to configure url = "https://
Just my opinion, but I'm fine with it.
Ralph
Sorry for my natural blindness. I've read the ticket as support of https serving on the graphite-clickhouse site.
There's no reason why querying CH shouldn't work. In my environment, it works perfectly. Here's my URL from the production config:
url = "https://user:password@hostname:8443/?cancel_http_readonly_queries_on_client_close=1"
What particular issues do you have?
I wasn't aware that it's possible to connect to https. Now after trying it ...
x509: certificate is not valid for any names, but wanted to match localhost
or with FQDN
x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0"
I'm using self signed certificates with FQDN as CN.
Ralph
@ralphM78 : try what second option suggest - use FQDN and set GODEBUG=x509ignoreCN=0 env variable. No sure is it has any performance implications, though.
@ralphM78 : PS: Another useful option - ditch out self sign certs and use proper cert using "Let's encrypt" but proper implementation needs to be automated ofc.
I have played around a little bit and now it's working.
Option 1 is to add Environment=GODEBUG=x509ignoreCN=0 through systemd. But not sure if this will work with future versions of go.
Option 2 is to create SSL certs with Subject Alternative Names (SAN). If one of the SAN is localhost, the url = https://localhost:8443 option will work also. Otherwise use FQDN. The system must of course trust the CA.
Ralph
What's the actual meaning of querying the same host with ssl? It causes a handshake overhead for every query. I wouldn't suggest doing it.
If it's network transmitted data, the best thing is a valid certificate, or at least a company-wide trusted one that every node knows.
Querying localhost with SSL makes no sense so far. I only have tested it. Another case could be disabling http <http_port remove="remove">8123</http_port> for the entire clickhouse cluster and only use encrypted traffic. Maybe a company-wide instruction or something like that.
This problem wasn't about an invalid certificate. The certificate is valid. It was about the missing usage of SAN for the certificate. This can happen with Letsencrypt certificates also, if there is no SAN.
Ralph