Comments/Suggestion welcome on the proposed security setup for uploading test data to a website.
We are designing some lab equipment and need to upload data to a website.
The design is using an ESP32 low power micro with built in WiFi and an SD card, internal to the lab equipment.
To connect using https to the website, we need to store a ‘root’ cert (CA) in the device.
It will be an annoyance to the customers if they have to update the CA on a regular basis so we want a
long dated CA to use to sign the website cert.
The website will only be accessed to upload data from the devices. It does not need to be accessed by
normal web browsers.
LetsEncrypt X1 cert, which is valid to 2035, has been suggested.
So the proposed system is to request a website cert signed by LetsEncrypt X1 and then install the X1
CA in the device.
As an alternative, we could use the process described here
to create our own CA cert and then use that to sign the website cert and store our own CA in the
device.
Since the ESP32 does not have any idea about the actual date, we assume it won’t care about either the CA or the website certicate expiring (but we need to check that).
Using this process, the only time we would need customers to update the stored CA would be if the CA keys were compromised.
Comments suggestions on the security of the system welcome.
This will be a problem as all certs have an end date but also a start date.
If the local system clock is out of that range, the cert will be treated as invalid.
You may need to provide NTP via the WiFi network.
[of course you could provide any "time" you want to them - "it's 1999 forever"]
I agree with @rg305 that you need to find out more about how your environment will handle certificate validity.
I just wanted to point out that Let's Encrypt doesn't currently let you request a certificate signed by a specific key. Nonetheless, there are intermediate certificates available which will let you serve a certificate chain which chains either to the DST X3 root certificate or the Let's Encrypt X1 root certificate.
The difference is not at all in how you request the certificate, but in the intermediate certificate that you configure your TLS service with. Any current Let's Encrypt certificate can have a valid chain up to either of these two roots.
Thanks. The ESP32’s concept of time is milliseconds since the last reboot, so its SSL support library can not really check the cert expiry time.
It was the website I was actually concerned about. Would apache complain about out of date cert for the website?
Re valid chains. The ESP32 lib only needs (allows) on ‘root’ CA so as long at X1 is visible in the website cert then that should be OK. Note exactly sure how chains work. I am assuming here that if
X1 -> intermediate -> website cert
then the website cert has the details of X1 included in its cert so that X1 can be used directly to verify the website cert
Does that matter? I thought the intermediate certificates with the same X1/X2 designation all used the same key pair? I.e., the X1 signed by Identrust uses the same keypair as the X1 signed by ISRG, the X2's use another keypair, but the same between the two roots et cetera. If that indeed is the case, it shouldn't matter which root cert is embedded, as long as the server sends the right intermediate (i.e., signed by the root embedded in the device).
Personally, I'd say any custom embedded device connecting to a server owned by the same company should use a private certificate authority. The Nest Thermostat for example uses a non-public (i.e., private) root certificates for its connection with the Nest servers.