1

I'm developing an IoT product's software, where it runs HTTPS client.

Given that the certificate of servers are renewed every year, it's not that issue while we're authenticating against the Intermediate Certificate (as Let's Encrypt).
Given those certificates have also a lifetime, so a solution might be to select a CA which have a long lifetime [Longer than the product lifetime (perhaps ~10 years)].

Given this suggested solution, what are recommended CAs for meeting this criteria?

Alternatively, is it a workable approach to update the stored CA certificate before changing the server's certificate by 3 months of the expiration of both CA and the server's certificates?

About limitations: could the server hold two different certificates within this update period?

6
  • What servers does your device connect to? Just yours, or third party servers? Do you connect directly or may there be proxies in the way? In the best case you just don’t need to use public PKI, you can just have your own root and intermediate certs (you need to protect those carefully). Still, a way to update your root certificate store on the device seems like a good idea.
    – jcaron
    Sep 16, 2023 at 20:54
  • It's an owned servers without proxies. Good to refer to custom certificate, but the same server hosts website, thus self-signed is not a proper choice. If it's possible, I think if the server hosts another webserver that uses different port and with different certificate, it will be a solution. Sep 16, 2023 at 21:27
  • Per the certificate update approach and in that 3-months period, which certificate the server will run? I don't think it can claim two certificates concurrently... What do you think? Sep 16, 2023 at 21:29
  • You can have a separate domain name on the same server and use different certificates for each.
    – jcaron
    Sep 17, 2023 at 9:22
  • You can have as many root certs as you want on your device, and your device will check that the certificate it receives can be traced back to any of those. That’s how web browsers work: you have dozens of root certificates in your trust store.
    – jcaron
    Sep 17, 2023 at 9:23

1 Answer 1

1

When a TLS connection is established, the server will present a certificate, and possibly intermediate certificates.

Your device should then decide if it trusts the presented certificate. It does so by having a trust store, where it holds certificates it… trusts.

A certificate presented by the sever may be trusted if:

  • The certificate itself is trusted. This is how you would be able to work with self-signed certificates, for instance.
  • One can establish a certificate chain from that certificate to a certificate which is trusted. This is the most common case.

In the latter case, the device will check who signed the certificate (it will give the identity of another certificate). It will try to find that certificate, either in the list of certificates presented by the server, or in the trust store.

If it doesn’t find the signing certificate, then the original certificate cannot be trusted.

Then it will check that the signature on the original certificate matches the signing certificate. It it doesn’t, again, the certificate won’t be trusted.

[skipping a number of other checks such as validity dates, hash types and sizes, etc.]

Now we know that the original certificate (A) was signed by another certificate (B). If B was in the trust store (more specifically, trusted to sign other certificates), then that’s it, since A is signed by B and we trust B, then we trust A.

If B was not in the trust store but in the list of certificates presented by the server (an intermediate cert), then we start the process again, trying to find who signed this cert, whether we can trust it, etc.

There are different ways of establishing what certificates your server will trust.

The normal way in a public PKI, like that used to check domain names in browsers, is to have a (looooong) list of “root certificates” in the trust store. Each vendor, independently and/or in cooperation with the CA/Browser forum will decide which Certification Authorities (CAs) they trust, and thus which root certificates to include.

That list is frequently updated, with new root certs added, old ones replaced, and sometimes certs removed altogether (when the device vendor and/or industry consider that the CA is not trustworthy and has issued certificates incorrectly, or is at risk of doing so).

In some cases the private key of a cert may be leaked. In such cases the associated certificate can no longer be trusted.

Also remember that when you renew your certificate, there is absolutely no guarantee that it will still be signed by the same chain of certificates, or even the same root.

So the public PKI is a living thing. You just can’t rely on a small and fixed list of root certs if you use it.

If your device has the ability to hold a full certificate store, you should have that, and include a way to keep it updated. You can for instance find curl’s CA list, extracted from Mozilla, here.

The alternative is not to use the public PKI, but to have your own CA and/or certs.

Some people will just store the server cert directly in the device. Others will set up they own CA, store the root cert of the CA in the device, and issue certificates signed by that CA for their server.

In any case, it’s still a very good idea to be able to:

  • Store multiple trusted certs
  • Have a way to update that list

The mechanism will be exactly identical to the public PKI case. The differences will be that:

  • The list of trusted certs will be a lot shorter, so on very constrained devices that can help.
  • The list of trusted certs should be updated a lot less often. Again, that could help for some devices with limited connectivity.

The fact that your server is also accessible by browsers is not an issue: just point two different names to your server, and use different certificates, one from the public PKI and another from your own. Use the domain with the public PKI cert for generic users, the other for your devices.

However this would fail if your devices end up behind a proxy or firewall (explicit or transparent).

8
  • Thanks, that what I think is a better approach, but can you tell me more about the proxy or firewall issue? Do these prohibit communication with "untrusty" servers? Sep 17, 2023 at 14:34
  • By storing multiple trusted certs and a way to update them, what is the estimated size of them? ((Just found the size by the provided link in the answer, it's about 217kB, which is somehow large)) Sep 17, 2023 at 14:34
  • @HamzaHajeir I have no idea of the constraints for your device (in terms of storage, CPU, connectivity…) so it’s difficult to give good advice. If you can, the full set of trusted certs is probably the simplest approach. If you can’t store that many, then a private CA may be the only option, but that means quite a bit more work for you to plan ahead and secure everything.
    – jcaron
    Sep 17, 2023 at 14:47
  • If your device ends up going through a proxy or firewall then it is quite likely those will only accept certs in the public PKI.
    – jcaron
    Sep 17, 2023 at 14:48
  • Does this apply to TLS v1.3? AFAIK Server Hello's certificate is sent to the client encrypted. Sep 17, 2023 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.