SSL and IOT devices - Never hardcode intermediate certificates and more


I don't understand what you meant by

Can you elaborate ? What do you mean by that ? Do you mean that ssl clients should be able to download new intermediates ?

Also, for example, say ISRG X1 is revoked tomorrow, how would IOT devices have to handle that ? Can we know is advance which root certificate would replace it and build it in the firmware ? For the intermediate R4 is already there to handle a potential R3 revocation, does that mean that the firmware should always include R3 and R4 ?

I'm sorry for the amont of questions but as you said, clients other than browsers are critical so I want to make sure of what the best practices are.

1 Like

Hi @Suorong

yes, that's required. Always.

1 Like

ACME clients should use the intermediate certificate provided by the ACME server when getting a certificate.

That said, the certificates actually do contain the issuer certificate embedded in it, but not every SSL client uses that information to download the extra certs required.

By having a backup CA. Never ever have a single point of failure for such critical devices (probably without easy upgrade capabilities).

No, the firmware should not pin intermediate certificates as if it were root certificates. We're talking about intermediate certificates served by the webserver here, not which certificate is trusted.

1 Like

The best approach is:

  1. Only roots (like ISRG Root X1) are in the trust store of clients/devices.
  2. Servers send any needed intermediates along with the certificate.
  3. Clients can then validate the connection even when the intermediate or chain changes.

Any system that checks or stores the intermediates directly is fragile at best.

And any device/client should have more than one trusted root/CA, just in case there's a problem with a specific root or CA.

1 Like

PS: I see, a little bit inexact. The ACME-client should download and install the current intermediate.

It's the job of the CA to send the correct intermediate.

1 Like

So if I understand correctly, for IOT devices we should be using at least two different root certificates in case one is revoked. Question is, does Let's encrypt have a backup root certificate ? I understand ISRG X2 can't be it because it's not RSA 4096. So which will replace X1 ? If Let's encrypt can't tell, does that mean we need to have 2 trust chains ready at all times in parallel ?

1 Like

Yes, your IoT devices should be having a root from Let's Encrypt (like ISRG Root X1) and at least one root from some other CA, possibly one you generate yourself. While Let's Encrypt is amazing and I expect it to be around indefinitely, it could have some kind of security breach, or run out of funding (it is just run on donations, after all), or there could be some other technical issue that requires issuing new root certificates. I wouldn't want anything that my business needed to operate to be reliant solely on being able to get certificates from one specific root certificate forever. If nothing else, ISRG Root X1 expires in only 14 years, so there better be some way to switch to more roots before then.


I see.

Right now Let's encrypt is moving from DST Root CA X3 to ISRG X1, how should this transition be handled? Should the IOT should be able to hold 3 Root CA to handle the transition smoothly, if so, isn't that a but much for an embedded devices ?

Also if you take into account that some devices might stay in stock or on shelves for a long time, a smooth download of a new firmware rotating an expired/revoked CA with a new one is not guaranteed, if the backup CA expired for example (or if both were revoked even if highly unlikely). Should firmware updates be done without ssl altogether or is there a cleaner and more secure solution ?

1 Like

Better title :+1: ...

1 Like

DST Root CA 3 expires this year, so if I were setting something like this up and using Let's Encrypt I'd use the "alternate" chain on my servers that just uses ISRG Root X1, and have that root in my devices.

Your firmware updates should probably check some signature that it comes from you, sure. Using https and running your own private CA for the firmware update server is a reasonable approach, though there are others. I wouldn't trust everything to a root that you don't control, but if you wanted to use ISRG Root X1 as your "main" approach and have your own private CA (or maybe a few other public CAs) as a "backup" for if there's some problem with getting a Let's Encrypt certificate using that root, that seems reasonable to me too. Or maybe you could put something together with HMAC-SHA-256 or the like to validate the firmware image even though it's received over unencrypted http, though that would require the secret itself being embedded in the devices which you might not want.

1 Like

Are you now talking about the trusted root certificate store for the TLS clients or the intermediate certs (and their signing root certs) for a TLS server?

Best solution would be your own private CA which could have a root cert with a very, VERY long expiration date.

The trusted root certificate store for the TLS clients

Yes, so there is no security issue with having a self-signed certificate at least for an IOT firmware update sub domain, as long as we are keeping the private key very, very safe. Right ? But still, if you want to be extremely sure that firmware updates will always go through, you would need the firmware update to either switch to the non-firmware update specific CA or have a second self-signed CA embedded as well.

Well, that's a lot to consider. Thank you very much for your quick and detailed answers guys.


Well, it's as secure as you keep the private key, yes.

Cryptography is just a very big lever: It makes the security of a large amount of information (the data) dependent on the security of a small amount of information (the key). But that's "all" it does, is make you care about the security of how you transfer keys instead of how to securely transfer everything. If you "outsource" part of that key-security to a CA like Let's Encrypt, that can be helpful but still ultimately you're just trusting that the public key for ISRG Root X1 was transferred securely to your devices and that the holders of that key only sign other public keys the way they've promised to.


By this, are your meaning that the ISRG Root X1 certificate was securely added to the devices' trust stores (since the public key for ISRG Root X1 is part of the ISRG Root X1 certificate itself)?

Yes, that's it. All a PKI does (including the public WebPKI) is reduce the security of everything to the security of getting the right roots into the device's trust store and the security of the entities that have those root keys (and the intermediates they sign, and so forth). If you can't trust that process, then you haven't really gained anything.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.