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.)