ESP32 Forum

Hello.

I have a project built using an ESP32 with Micropython. I am relying on an external MQTT broker - namely mqtt.thingsboard.cloud. How I have currently set up the device is that it only trusts the root certificate of mqtt.thingsboard.cloud. This certificate is provided by the company hosting the mqtt.thingsboard.cloud server here: https://thingsboard.io/docs/paas/user-g ... a-root.pem.

The problem is that their root certificate expires in 2029, and I need a longer lifetime for new devices that are being shipped out (at least 10 years):

I would need some help understanding how I should go about here.

FIRST QUESTION:
I do not really understand how the certificate expiry process works. I know that the device will not be able to connect to the server after the expiry date (December 31, 2028). But what happens the period before that? I assume that Thingsboard would provision a new root certificate someday. I would imagine that this will happen before the expiry date, so that there is a transition period, where both the new and old root certificate works. But I do not think that this is reality - correct?

SECOND QUESTION:
This leads me to the second question. I will need to renew the root certificates once they have expired. Currently, I see two options:
1) Hosting my own MQTT server with a longer certificate expiry period. I have not gone down this route yet, so I am unsure if I can get a certificate that expires in 10+ years without paying a lot of $$.
2) Implementing OTA on a separate server - also with a longer certificate expiry period. This server would be able to provision new certificates even when the MQTT connection starts failing in 2029. However, it will not run forever - eventually that OTA server's certificate is going to expire, and then there is no way for OTA updates to happen.

And my question here is then - are these my only two alternatives? Is it anything else that I should consider?

Note that I require MQTT-over-TLS, so if I am going to do OTA it must also be over TLS. Switching to anything that is more insecure than what I currently have is not an option.

Absolutely not an expert at this, but maybe I'll throw in some words which can help you with searching for an answer

My best guess would be, that you don't need to use the CA you mentioned, but use one of the newer CA's, as they are cross-signed by the one you mentioned.

You might want to checkout this page at the Sectigo site.

FIRST QUESTION:
... I assume that Thingsboard would provision a new root certificate someday. I would imagine that this will happen before the expiry date, so that there is a transition period, where both the new and old root certificate works. But I do not think that this is reality - correct?

I guess the process is like
1. As we approach the expiration date of the CA root cert, all certificates signed by that root certificate will (additionally?) be signed with a new root certificate, from the same or another CA. Instead of (re-)signing existing certificates, new certificates may be created in the process.
2. The new root cert will be published well in advance (years maybe) of the expiration date, either explicitly by the specific CA or implicitly by other CAs which have already published their root certs and which the site owner may choose as a replacement.
3. The usual way of managing CA certs' lifetimes on a client is to update your local database of trusted CA certs from time to time. With the IDF, this "local database" is the "certificate bundle" which can be generated from a set of CA certs included in the IDF and updated regularily.

SECOND QUESTION:
I will need to renew the root certificates once they have expired. Currently, I see two options:
2) Implementing OTA on a separate server - also with a longer certificate expiry period. This server would be able to provision new certificates even when the MQTT connection starts failing in 2029. However, it will not run forever - eventually that OTA server's certificate is going to expire, and then there is no way for OTA updates to happen.

As mentioned above, updating the list of root certs from time to time, e.g. once a year, will be necessary. This can and should happen long before any root cert actually expires. While the problem may seem recursively unsolvable, it is actually solved recursively You basically download new certificates over a connection secured by an old certificate while the latter is still valid.

Note that a 3rd party website may switch to a different CA root at any time if&when its owner chooses to, so it's a good idea to keep a somewhat current CA database on the client anyway, independent of 'hard' expiration dates.