ESP32 Forum

Hi,
We have a product with devices out in the wild. The hardware is a custom board running wroom32 module. It shipped using ADF with ESP-IDF v3.2.

The device has functionality to check for FW update with a server and then upgrade using esp_https_ota() function. A root CA certificate is included in the configuration for the OTA. This certificate has long since expired. I am now seeing some devices connecting to the server and failing to update because the SSL connection is not valid. The CA is Organization: Digital Signature Trust Co.Common Name: DST Root CA X3. The OTA firmware file is hosted on Firebase.
I can download the firmware bin file from a browser so it seems the expired root CA cert on the device is the problem.

I have two questions:

1. We own the domain name the device tries to download from. Can I configure a server somehow to work with this old expired certificate? (I don't care if it is not secure)
2. In general how does one prevent this situation from happening? It is not possible to guarantee that all devices sold will be OTA updated with new fw (and root CA certificates) in a timely fashion.

Thanks,
Felix

Okay, I did a bit more reading and found that this is a well known issue. Question 1 still stands.

Can I configure (some would say misconfigure ) a server that I control such that it will allow https connection from client with the old cert?

We own the domain name the device tries to download from. Can I configure a server somehow to work with this old expired certificate? (I don't care if it is not secure)

You can certainly do that, provided you have access to the server certificate, private key (and possibly passphrase for the private key).

Details will vary depending on which httpd you use and you may need to jump through some hoops to get a server to operate with an expired certificate chain. Push come to shove you can always write a small server yourself. The question is: do you have the expired certs & keys or were those part of the all-inclusive hosting a firebase?

Typically though, it's the client that will balk at expired certs, not the server. It looks like the error message you posted is from an esp device. Since you can download from a browser and are hosting the firmware on firebase, it's reasonable to assume the server cert is not actually expired but has been changed entirely.

So long story short: it looks like your esp (tls-client) is expecting the expired certificate chain and the certs for firebase have been updated. This should work no problem if you can serve the file at the domain with the certs that your device expects.

Question 2 is more tricky: you do need to ensure that devices get updated with new cert bundles in a timely fashion, i.e. before the previous certs expire. Otherwise it will require physical intervention to update them. Since most embedded devices can't keep time anyway , the actual expiration is secondary, though. You're probably not checking CRL's either. A popular strategy is to set the cert expiry to beyond the expected lifetime of the device (or at least past your point of retirement). If you issue your own certs you can set arbitrary expiry times (CAs will usually restrict you to two years or less) it's perfectly ok to use your own CA with embedded devices, because you control the client...