What does CONFIG_MBEDTLS_HAVE_TIME_DATE exactly do?

[linuxman]

Hello!

I'm working on a project implementing my own OTA application similar to simple_ota example found on Github. I was wondering about how can I check whether the certificate used is expired, and I found this thread on this forum: viewtopic.php?t=7585. I understand that by enabling CONFIG_MBEDTLS_HAVE_TIME_DATE in menuconfig, this check can be made. I also read the documentation that says:

System has time.h and time(), gmtime() and the clock is correct. The time needs to be correct (not necessarily very accurate, but at least the date should be correct). This is used to verify the validity period of X.509 certificates.

It is suggested that you should get the real time by “SNTP”.

My question is: How will this time later be stored on the device? After enabling this option, will the device work as a clock, as well?

[Angus]

Hi linuxman,

Thanks for pointing out that the help for these items is not very informative, we'll fix this.

Enabling this option will cause mbedTLS to include functionality for reading the date and time, and it will use this to check certificates are unexpired at the current time (ie the current timestamp is between "valid from" and "valid to"). This won't be useful unless you also have some code to set the time. For these reasons it is not enabled by default.

Setting time via the network is most commonly done via the SNTP functionality built into LWIP. An example of the SNTP API can be found here:
https://gitlab.espressif.cn:6688/espres ... cols/sntp/

However you can set it in another way if you prefer, by using the standard gettimeofday()/settimeofday() APIs.

We don't have an example that persists time over restarts (apart from deep sleep). In the SNTP example the time is always zered after a cold restart and is set after Wi-Fi connects. You could use NVS to periodically save a timestamp to flash though, and then load this on restart (note that you don't want to do this too often, to avoid wearing out the flash - suggest once a day is probably enough if your only concern is certificate expiry.)

As well, just a heads-up: there is nothing wrong with checking certificate expiry on embedded devices but make sure to think through the possible corner cases over time. Especially if a device is set to only trust one or two certificates. For example, if someone powers their device off for a couple of years, and the only trusted certificate on the device expires during this time, will it be able to recover once it's powered back on?

If the device only trusts one or two certificates, an alternative approach can be to explicitly "revoke" these by OTA updating to a new firmware version that doesn't trust the old certificate any more. There is a security tradeoff here - an out of date device that hasn't had any OTA updates for a while could potentially still trust an old certificate that has somehow been compromised, but the alternative (automatically expiring that certification) would mean that this device is bricked.