How to organize server SSL certificate verification on the device?

Question

Iron

There is an iron device communicating with the REST API via HTTPS. The server has a normal certificate issued by Comodo. How to properly organize certificate verification on the device in the long run?

You can throw a Comodo certificate on the Root device and check it, but

1. In this case, all subsequent updates of the server certificate will have to be carried out with Comodo and hope that this company will be in good health;
   
2. The Comodo certificate also expires at some point. Not tomorrow, but still.
   

Another option, which is not much better, is to upload up-to-date certificates of all key certificate authorities, as , for example, Node.JS does . In this case, at least we are not tied to one certification authority, but other problems remain.

A self-signed certificate is not an option because browser clients must communicate with the same REST API.

Enlighten on how to solve such a problem. Perhaps I do not understand something.

Answer 1

If you have "pieces of iron" that will later be difficult to update, then it's better to file your certification authority and a self-signed certificate + get the opportunity to file the authorization of pieces of iron according to client certificates and the ability to cut off access if something went wrong :)
And the best way is not reinvent the wheel and provide for the possibility of updating the hardware by the user and, if necessary, updating certificates / software / etc
Well, it's not clear what you mean by "device".
We sawed terminals on raspberries and sawed exactly the self-signed one with authorization by client certificates, because the API for WEB and hardware owners was different in terms of functionality.

Answer 2

Issue using HTTPS in ESP8266 and ESP32
https://www.youtube.com/watch?v=Wm1xKj4bKsY