How should one handle expiring TLS certificates?

[HenryM]

I've not done much work using HTTPS, but here's what I have so far.

1. We have a server running at https://mydomain.azurewebsites.net
2. I obtained a root certificate via the command openssl s_client -showcerts -connect <server_name>:443 </dev/null
3. I am able to validate my connection, send data, and receive responses

I parsed the data held within the certificate and it looks like it will expire in about 5 years. When the certificate expires, I don't think my application will be able to work any longer, is that correct? Do I need to set up a method of bootloading applications every few years to ensure that I don't end up with an expired certificate?

Edit: My code is based on the https_request example.

[WiFive]

Yes, some certs like aws can be valid for 20yrs, but regardless you should set up a method to update or revoke certs and a method to notify your users of required updates. It can be via ota or serial flashing.

[ESP_Angus]

Hi HenryM,

By default, in ESP-IDF mbedTLS is compiled without date/time support so the device doesn't check the expiry of certificates at the device end. This can be optionally enabled.

In most circumstances it's best not to enable expiry checking, for the reasons you're thinking of. If you need to replace a certificate with a newer one, you can OTA update your devices to add the newer certificate. (mbedTLS can load multiple trusted certificates, so you can have a transition period with the old+new certs both trusted by the device).

As WiFive mentions, if you compile in root certificate(s) from the "root" of the certificate chain then this can have a longer expiry period compared to the inidividual certs you may be using, but it will still expire. (For example, for Azure the root cert is the "Baltimore CyberTrust Root" which is valid until 2025).

However, at some point Azure will change root certs (this was the announcement from last time when Azure moved to their current root cert). Provided that you get the announcement in time, you can roll out an OTA update which trusts both root certs and then remove the old root cert after Azure is no longer using it.

However, that's a big "Provided that" given that there may only be a short notice period given, and all devices need to update in that window of time. Rather than doing this, It's much safer to use the custom HTTPS hosting features in Azure (or another service) to load your own custom certificate chain for which you hold the private key. If the endpoint for this certificate chain is only accessed by ESP-IDF devices, it can even be a self-signed certificate (ie not signed by a "real" trusted CA). This way, you have full control over if/when you transition to a new certificate (or a new root certificate). You could even migrate your devices away from Azure in the future if you needed to (provided you also control the domain name they connect to.)

[HenryM]

Thank you for the explanation. I'd like to restated it to make sure I understand the current situation.

Since I'm using a root certificate which we do not control, when it expires HTTPS will fail to work. If we continue down this route, this means that we'll need to use OTA to ensure that we do not lose the ability to communicate with the server. Even if we support OTA, there is a possibility that not all devices will be updated in time. I think that this is a very likely scenario to occur since we're doing this project under contract for an outside company, will not be able to ensure that they monitor this closely, and they have not yet agreed to pay to develop the OTA infrastructure.

If we don't care about the expiry date of a certificate, then we can load our own certificate to our server. We can use the public key in our ESP32 application, and so long as we leave date/time support disabled in mbedTLS, we do not need to worry about bootloading in a new application.

Thank you again for your help!

[darrenbsydney]

I believe I have solved this although I am by no means an expert..

Originally I was running Let's Encrypt and certbot on the server to create and manage certificates. I've now turned off certbot so that it no longer manages the specific site that I am hosting firmware updates from. I'll have to self manage these myself from no on. This was done using "sudo cerbot delete".

I then created my own public / private keypair on the server as well as a self signed certificate using "openssl req -x509 -newkey rsa:2048 -keyout ca_key.pem -out ca_cert.pem -days 365 -nodes", but changing the days to 5000 so the certificate created expires in 2035.

I then put the private key and certificate in a secure location on the server and then redirected the ssl configuration for apache to reference these files instead of the references to the lets encrypt files that it used to use. And restarted the web server.

At this point it works as a web server. I can browse to the site, although there are warnings about the certificate being self signed. That's ok, the site is not intended for web browsers. Checking the certificate on this site from the browser it shows a 2035 expiry date.

I then copied the certificate to the server_certs directory in my esp project.

Importantly the https ota updates from the esp32s2 work to this server.