ESP32 Forum

Use case: when I access a HTTPS site from my browser on my windows machine, I have a selection of trusted root certs and the remotes cert is validated automatically against these trusted certs.
However in the ESP32 HTTPS examples it works differently: I have to provide upfront the correct server certificate or root certificate.

My idea: store all common root certs on a files system such as SPIFFS or SD-Card. I.e. Mozilla provides a csv with all trusted certificates. But I have not much knowledge with mbedTLS. So far I've been using the Arduino HTTPSClient. But I would be really grateful if someone could outline a solution on whether this is "easily" possible with the ESP32-IDF or Arduino libs.

@Angus, do you have an idea on that?

https://support.dnsimple.com/articles/w ... ate-chain/

The more certs in the chain between root and server the more resources it will take to verify.

You can simply concatenate multiple root certs into a PEM file (which you will embed into the flash, and then provide to mbedtls_x509_crt_parse. Personally I used in my component.mk, but SPIFFS is a good idea also). In fact, you can also add comments that won't affect the certificate data but can help refer to the details of which root is which.

For example, check out the format of this file (which Google provides as a recommendation to be safe against future root CA changes [for any Google-owned services].)
https://pki.goog/roots.pem

Thank you for your replies so far!
Root CA validation has not been an issue so far for us performance-wise. The problem is: for some of our services we cannot guarantee that server or root CA might change. (such as you don't do that also when you browse normal web pages)

One additional thought: when I parse a file with 300kB worth of certificates, wouldn't I immediately run out of RAM? Wouldn't it make sense to have some sorts of lookup table and then just parse the needed certificate?

Unfortunately I don't have much of a better solution than loading a minimal set into RAM via mbedtls_x509_crt_parse. Personally I stripped Google's recommended file of the comments, and removed most of the certs.

For me, Google + Let'sEncrypt covers pretty much everything I intend to use and ~10 root certs in a single PEM file covers that. Google (wisely) includes some backup CAs in their bundle, so perhaps include a few Digicert roots for their most-likely backup CA.

I do have a (rudimentary) lookup table of sorts (actually, my HTTPS C++ class requires some PEM text to connect). So I only submit the Google CA roots when connecting to a known-Google-using endpoint. The rest of the connections I provde the Let'sEncrypt roots.

There are some potential issues with pinning even the root certs (the lookup table approach), for example this year Google migrated all their services from GeoTrust/Symantec to GlobalSign, and in 2018~2019 they will migrate *again* to their own CA (Google Trust Services / GTS), presumably so they won't need to do this again (they were "burned" by Symantec trust issues).

So for a while (at least for Google) multiple CAs will be in use at the same time and the migration to your endpoint can happen at a specific time without warning. I suppose the lookup table approach would have to be extended to have some alternates in case the cert doesn't verify. That is effectively how it works in my case, where for "Google things" I supply all three CAs (and a possible backup CA) they might be using.

look at ~\gnutls\lib\system\certs.c for inspiration.