1
votes

I have a problem with insecure SSL certificates. My proyect consist on two parts:

  1. ESP32 iot device with a https server
  2. VUE2 + Vuetify PWA web app deployed to firebase hosting.

Imagine that one client buy my iot device, and connect it to the power. The device will boot in AP mode, creating a WiFi AP net. The client login to the web app and wants to add his new device. So, for that, the iot device needs clients wifi credentials. The web app asks to the client his ssid and password, and when the client click on 'Configure device', the web app send a https POST request to the esp32 server, and here is the problem... Because the SSL certificate used in esp32 server is not validated by an authority, the web app can´t make the POST request...

How can I get a valid server SSL certificate for a lot of iot devices? I don´t know how to manage this situation...

Thanks everyone!!

1

1 Answers

2
votes

It is possible to get a valid SSL certificate for the device, but I wouldn't recommend it. Here is how you could do it if you wanted to:

  1. Ensure that when your device is in AP mode, it's always available at the exact same IP address. For example, ensure that the ESP32 is listening at 192.168.1.1.

  2. Register a domain like example.com. Add an A record to your DNS server for iot.example.com, with the value 192.168.1.1.

  3. Obtain a valid SSL certificate for iot.example.com from any trusted authority. Put that certificate and associated key on your device.

Now, when your user connects to your soft AP, they can browse to https://iot.example.com and actually see a valid certificate.


However, I would really recommend not doing this. You'll have three major issues to contend with:

  1. The key for your SSL certificate will be on your device's flash. If anyone extracts it, they can masquerade as iot.example.com. You can mitigate this by using flash encryption, but it's still not great.

  2. The maximum validity period for an SSL certificate is around two years. So your provisioning flow will break after a couple years.

  3. If the CA that issued your certificate hears that the private key is floating around and could potentially be compromised, they will probably revoke your certificate.

Instead, what you should do is secure your soft AP with WPA2, and a password that you can give to users. This will ensure that the connection is encrypted, and you can serve your provisioning form over HTTP instead of HTTPS.

An even better approach rather than trying to implement this yourself, is to use the ESP-IDF unified provisioning API. It takes care of the implementation details, and supports both Wi-Fi and Bluetooth as transports.

Regardless of what you decide to do, I'd highly recommend reading the ESP-IDF documentation on unified provisioning and the documentation on Wi-Fi provisioning, since they'll give you an idea of what's going on under the hood and what all is required for a secure implementation. In particular, you'll see that the Wi-Fi provisioning library does actually use a static WPA2 password like I suggested above.