Trusted CA SSL certificates and embedded devices

Question

There is an embedded device which should connect to the server over HTTPS and MQTTS. A server certificate is issued by a trusted CA (for example, Let's Encrypt). But there is a problem with server certificate verification on the client side because the device doesn't know about trusted CA's.

So I have a few options:

1. Put a DST Root CA X3 root certificate (LE root cert) into the device and check against it;

2. Make a self-signed root certificate and put it into the device;

3. Public key pinning.

The first approach doesn't work because the DST Root CA X3 will expire next year. Furthermore, Let's encrypt may change their root certificate at any time and we can't guarantee that newly issued certificates will be signed by the same one.

The second way makes my HTTPS server not trusted for other clients like web browsers.

What about using multiple certificates at the same time? Is it possible? If I'm not mistaken Nginx server supports it, but I'm not sure it works in the way I guess: if the first certificate (e.g. Let's Encrypt) verification fails a server would give a fallback certificate (e.g. self-signed) to the client. Even if so not all servers support this.

The third way is to put my server public key hash into the firmware. In this case I can use any CA in future (am I right?). The only thing I should be careful about is always using the same keys when generating CSR.

Which way is better? Or are there any other solutions for my problem?

Answer 1

It actually does not matter for the question if the trust anchor is a publicly trust root CA, a locally trusted root CA or a locally trusted server certificate. What matters instead how to deal with the situation when the trust anchor should not be trusted anymore.

A simple approach would be to have a trust anchor which is valid forever. This is the way you are trying to go and it could be implemented the following way: let an arbitrary public CA issue and later renew the server certificates but use the same fixed key pair for each of the server certificates. Then pin to the servers fixed public key in your device. This way the device will be happy with verification since it only checks the expected public key. Browsers will be happy too since the certificate was issued by a CA they trust.

Only, what happens if the servers key gets compromised? This is a similar situation you face if your trust is based on a public root CA and the CA expired. In both cases your trust anchor should no longer be trusted. Thus you need to somehow switch to a new trust anchor.

If you've pinned against the servers key you might have an alternative key pre-created and put into the device which is used in case first key was compromised. On certificate verification you then check against this alternative key if verification fails with the primary key. If this succeeds you know that the primary key is considered obsolete and should never be used again for verification. You could also have multiple alternative keys so that you could obsolete more keys over time.

Still, no key should be trusted forever since with the time the chance increases that the key got compromised or got too weak. So you very likely need to have some way to update the software in your device. This is usually needed for bug fixes anyway but could also be used to bring new trust anchors to the device, no matter if these trust anchors are new trusted root CA's or trusted server keys.