How can I make an SSL certificate for an IoT device trusted on all browsers?

Question

I have a web server running on an IoT device, more specifically, on an ESP32.

This web server serves a website that is used for managing the device and can contain some sensitive information, hence I need to serve the website using HTTPS. The problem is that a client who uses our device will have to accept the usual error on their preferred browser since my SSL certificate is not signed by a trusted authority - it's self-signed.

To the best of my knowledge, I cannot get my certificate signed for an IP address of the web server because they only accept Domain names.

• So what is the best way around this?

Any suggestions are greatly appreciated because I have hit a brick wall.

Answer 1

Do not reuse the same certificate and private key on multiple devices. The private key can and will be extracted from the device. Even if you managed to install a valid & CA signed certificate, anyone would be able to mimic your server. A man-in-the-middle situation would be equally insecure compared to using plain HTTP or a self-signed certificate without manual validation of the fingerprint.

The correct way

Every IoT device having enough computing power should behave like this:

1. During the initial setup (and at any point after), allow the user to decide the hostname of the device. It could default to the IP address of the device, which would be fine if the client chooses to use self-signed certificates.
2. Create a random key for the individual device that isn't just derived from predictable variables, like the serial number or MAC address of the device. Neither stick with a static key for the device for its entire lifetime; generate a new one every time.
3. Using the random key, create a self-signed certificate for the hostname.
4. Allow the user to download a certificate signing request (CSR).
5. The user can now sign the certificate in a way appropriate to their infrastructure, whether it's a local PKI or a public CA, using a FQDN of a (sub)domain they own.
6. Allow the upload of this certificate. Validate it's still a pair of the private key and replace the self-signed certificate with it.

Answer 2

You can't.

You're essentially asking "I want the whole world to trust me that I control 192.168.1.100". If you could request that, then anyone could. Obviously, we don't want random people and organizations to gain arbitrary "trusted IPs" in local networks.

Your Options

The problem "I want people to be able to connect to my server in their local network" isn't new, so there have been plenty of solutions:

Just use HTTP

On an internal network, it is very unlikely that an attacker will be able to use a Man-in-the-Middle attack. After all, if an attacker can sniff and decrypt your local wireless traffic, they need to be physically close and have cracked your Wi-Fi encryption key.

Use a self-signed certificate

This is marginally better and trades one browser warning for another. A security-conscious user would then manually confirm that this self-signed certificate is trusted, which actually offers very good security. Or conversely, a regular user would just click "okay" on the warning and ignore it, which is basically the HTTP scenario again.

In essence, you're better off just using plain old HTTP and give users the option to create a new self-signed certificate on-the-fly.