Newbie HTTPS / SSL Advice

Telegraf
1

Hi Guys,
I am very new to all of this HTTPS / SSL stuff and trying to make it work with influx.
So far I have generated self-signed certificates, and have an ESP32 talking nicely through HTTPS into a database.
My next struggle is more to do with the underlying understanding of how SSL and more importantly certificates work.

When I have, say, 20 devices all talking to this database, they all need their own certificates correct? (As using one certificate for all is bad for security).

Does this mean I need to register 20 certificates with Influx?

I started reading about CA certs and this seems to be what I am after, but I cant quite make sense of it. A brief explanation would be a godsend.

Thanks in advance!

2

Hi

As far as i am aware, no you would just use the same certificate. This cert is for the database, not the telegraf agent. Then you would just point each telegraf agent to https://your-influx-instance:8086.

If you were using multiple database servers then you would need a cert for each.

We generate a self signed certificate for each database installation, which all telegraf agents on that network point to.

If you skip past the CA certs section in these docs, hopefully the section about self signed SSL will help clarify your understanding.

[InfluxDB and self signed certificates.](https://docs.influxdata.com/influxdb/v1.7/administration/https_setup/#set-up-https-with-a-self-signed-certificate)

Hope that helps.

3

Thanks for the reply,
Okay, I am not using telegraf (I dont think? I am just talking to the Influx HTTPS endpoint directly).

So each embedded device would have the same certificate, with authentication being handled by their respective usernames and passwords?

I have read through that a few times, and its how I got it working on one device in the first place.

4

When I have, say, 20 devices all talking to this database, they all need
their own certificates correct? (As using one certificate for all is bad
for security).

Correct. You could put the same certificate on every client, but if one
client gets compromised and you need to revoke that certificate, you then have
to create and install a new one on all the other 19 (as well as sorting out
whatever happened to the 20th).

Does this mean I need to register 20 certificates with Influx?

No. (Well, not if Influx works the same as every other TLS-capable
applications I’ve ever come across - I’ve not actually done secure remote
connectivity to Influx myself.)

Influx just needs the CA certificate.

I started reading about CA certs and this seems to be what I am after, but
I cant quite make sense of it. A brief explanation would be a godsend.

When you start creating certificates, the first thing you do is to create a CA
certificate, and you then use that to sign all your client certificates that you
create afterwards (note - be sure to create the CA certificate with a longer
expiry date than the client certificates, so that you still have a valid CA
certificate to sign the renewed client certificates with when the time comes).

Anything (in this case Influx) which then wants to validate any of those client
certificates can then do it in one of two ways:

a) make sure it’s a trusted certificate, but knowing what that certificate
should be. This means knowing about every individual client certificate.

b) make sure the certificate is signed by a trusted CA (in this case, your
own). This means knowing about the CA, but not about every individual client.

So, essentially you configure Influx to trust any client which presents a
certificate which is signed by your CA, without caring about the details of
that client.

If one client gets compromised, you can then put its certificate onto a CRL
(Certificate Revokation List), and Influx will continue to trust anything else
signed by your CA, but not that one.

I’ll leave it to someone else who has already done this with Influx to explain
where the specifics of such a configuration need to be set up, but I hope that
helps you understand the “chain of trust” a bit better.

Antony.

5

So, Influx SSL is for the client to trust that it’s talking to the correct
server, but not for the server to make sure only trusted clients are sending
it data?

That sounds rather the wrong way round to me (but I’ve never configured SSL
with Influx because I’ve only ever needed local connectivity within one
machine).

Antony.

6

Hi Antony,
Thanks for your very detailed reply.
That has reinforced what my (basic) knowledge of TLS / how it works.
This is a pretty similar to what I had in my head as to the workflow and the security aspects, I had already tried to implement this before but with no joy, but then again I have changed so many things in the last day I need to start fresh and see what happens.

As for what philb said, that does indeed seem strange but maybe correct? Can anyone clarify this?

If so, what is the best workflow for IOT style devices to poke data to an InfluxDB?

7

Fair enoughs, I’d assumed telegraf was in play here.

My overall understanding of SSL/TLS is limited, our set up consists of Telegraf sending data via HTTPS to influx which is signed with a self signed cert.

You’re right though, it does seem odd.

8

Looking into this a bit further, philB may well be correct. I seem to be able to curl data into my database without a correct private cert, regardless of what is set up serverside?

9

Oh, I’m sure he may well be correct - it is, after all, much more common for
servers to present certificates and clients to verify them (think of browsers,
where the user wants to be sure they’re viewing the website they asked for).

However, clients presenting certificates and servers verifying them are a more
appropriate solution where the server needs to be sure that the clients are
trustworthy rather than the other way around.

So, I was just surprised that the Influx model appeared to work the way it
clearly does.

Antony.