Client certificate authentication

Telegraf
1

Hi all,

I’m trying to set up client certificate authentication for sending data from Telegraf to InfluxDB.

I followed the instructions at Enabling HTTPS with InfluxDB | InfluxDB OSS 1.6 Documentation

The server has an https cert signed by LetsEncrypt, but I’m using self-signed certificates for the client cert auth.

The problem, at least as far as I can tell from testing with curl, is that InfluxDB is still specifying Basic auth even though a certificate has been provided.

On another thread one of the staff suggested that the only way to stop the use of Basic auth is to not have “auth_enabled” set to true, but according to the documentation, if auth_enabled is not set to true, no access control restrictions are applied at all. And it seems somewhat pointless to have cert auth if you can’t apply access restrictions to anyone who connects.

Can someone help, please?

Thanks,

Simon.

2

Hi @Simes

If you’ve followed the documentation i assume you have made the changes to your influx config. But you need to enable it your telegraf config.

You need to make sure that you have the following in your telegraf config

insecure_skip_verify = true

Also, in the telegraf configuration you should set the urls to HTTPS so

urls = ["https://ip_or_domain_name:8086"]

It’s usually the url part i forget and that catches me out.

Hope that helps. If not, it might help if you post a snippet of your config relevant to the HTTPS section

Regards

PhilB

3

Sorry, I obviously wasn’t clear enough. The server’s cert for securing https is provided by the LetsEncrypt certificate authority, I don’t need to set my connection to insecure for that to work, but even if I try that, the same problem occurs. Testing with curl shows an “unable to parse authentication credentials” error. The problem seems to be that InfluxDB is not accepting the client certificates I want to send to it.

http section of InfluxDB configuration:

[http]

  # Determines whether user authentication is enabled over HTTP/HTTPS.
  auth-enabled = true

  # Determines whether HTTPS is enabled.
  https-enabled = true

  https-ca-certificate = "/etc/ssl/my-ca/cacert.crt"

  # The SSL certificate to use when HTTPS is enabled.
  https-certificate = "/etc/letsencrypt/live/myhost/fullchain.pem"

  # Use a separate private key location.
  https-private-key = "/etc/letsencrypt/live/myhost/privkey.pem"

curl command and results:

# curl -vvvv --cacert /etc/ssl/my-ca/cacert.crt --cert /etc/ssl/client/client.crt --key /etc/ssl/client/client.key --data-urlencode "q=show databases" https://myserver:8086/query

*   Trying <myip>...
* TCP_NODELAY set
* Connected to myserver (myip) port 8086 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/my-ca/cacert.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=mycn
*  start date: Jul 23 10:21:26 2018 GMT
*  expire date: Oct 21 10:21:26 2018 GMT
*  subjectAltName: host "myhost" matched cert's "myhost"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> POST /query HTTP/1.1
> Host: myhost:8086
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Length: 18
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 18 out of 18 bytes
< HTTP/1.1 401 Unauthorized
< Content-Type: application/json
< Request-Id: d9a4e123-91c5-11e8-800e-000000000000
< Www-Authenticate: Basic realm="InfluxDB"
< X-Influxdb-Build: OSS
< X-Influxdb-Version: 1.6.0
< X-Request-Id: d9a4e123-91c5-11e8-800e-000000000000
< Date: Fri, 27 Jul 2018 17:52:38 GMT
< Content-Length: 55
<
{"error":"unable to parse authentication credentials"}
* Curl_http_done: called premature == 0
* Connection #0 to host myhost left intact

I’m not an expert on this but I have seen dumps of curl using client cert auth for connecting to other servers and in those, the TLS handshake section contains Request CERT and CERT verify sections. So it seems from this that the client cert isn’t being requested by InfluxDB. Please correct me if I’m wrong.

Thanks,

Simon.

4

Two weeks and no response, should I just give up on this?

5

Well, it’s been a month now and still no response. I can’t delay this project any further and so I’m going to recommend we look elsewhere for storing our TS data.

6

@Simes It looks like this documentation was added by accident ahead of the code change. InfluxDB doesn’t yes have built in support for client certificate authentication. I have poked the documentation team on this issue and I’m sorry about the confusion it caused.

You can use an authenticating proxy such as nginx or haproxy along with the settings in the Telegraf output plugin.

7

Hello daniel,

Do you plan to give client certificate auth for InfluxDB in the future?
I think it would be great.
I will try your suggestion to install and configure HAProxy to handle client cert access control.

8

I believe so, but I would keep an eye on https://github.com/influxdata/influxdb/pull/9698 for the latest updates.

11

Hi,

Try my tutorial. I hope it will help somehow.

1 Like