Hello, I have a project where GPRS microcontroller need to securely connect to the server.
I plan to use SSL, but my microcontroller can store only one root certificate in it storage.
So I decided try to use Let’s encrypt on my server and ISRG Root X1 root ca on microcontroller.
The question is - for how long Let’s encrypt’s root ca will not change?
…because microcontroller can work for decades 
I’ll answer with another question: is it really necessary to use a public Certificate Authority?
It sounds as you actually control the client yourself, as you are the one providing the trusted root certificate store. In that case: wouldn’t it be better to set up your own root certificate? From which you issue end user certificates (perhaps through an intermediate cert)?
For example, Nest uses this for their Thermostats. If you would monitor the network traffic, you would see the servers the thermostat connect to are providing a certificate (ultimately) signed by Nest’s private root certificate. They can do this, because they control the client, in casu the Thermostat, which trusts the Nest Private Root certificate.
I second what @Osiris said. If you control both ends, it’s often easier to use your own private certificates. A lot of embedded stuff works this way because of the need for long-lived certificate use and tight control on both sides.
To answer your question, however:
The ISRG Root X1 has an expiration of 2035. You can find out more information on the certificate chain at https://letsencrypt.org/certificates/.
Keep in mind that many of the currently issued certificates will not chain up to that root currently. Certbot and other clients will fetch the indicated intermediate, which chains to the DST root.
Notably the X3 intermediate is going to expire on October 6, 2021 (and may well be replaced significantly sooner than that). I’m not quite sure if this is a problem for this deployment scenario or not.
The intermediate would be provided by the server, which probably is more capable of being adapted than the GPRS µC @ujeenator is mentioning.
As long as the send intermediate is signed by the trusted root certificate embedded in the µC, @ujeenator will be fine 
Still, I would opt for a private CA. Even more so because Let's Encrypt isn't providing an elliptic curve root certificate, which would make the certificate way smaller compaired to the current 4096 bits RSA certificate. And the "early 2017" generation of an ECC ISRG root has passed silently unfortunately.
hi @ujeenator
TLS/SSL is not the only way of securing communications. There are a wide range of crypto protocols designed
I did a series on IoT security which you can review here: https://www.linkedin.com/pulse/learning-from-hackers-blackhat-defcon-iot-security-part-andrei-hawke-1
Few other points
A) You should be prepared for change. I know micro-controllers last 10 years however security and out implementation of it is constantly changing. Thinking something will last a long time is very dangerous. There may be things outside of your control (Let’s Encrypt needing to stop using a Intermediate due to compromise etc) that may make your network communications no longer work
B) TLS providers a good option but even if you run your own CA or use a device manufacturers CA you are still relying on them to protect their private key (or yours)
C) Cryptography is a toolkit - the acronymn CIA usually comes to mind and you need to focus on the aspects that matter to you. Is it secure communication of data (Confidentiality) or Integrity of Data (Ensuring the client and only the client is sending the data)
D) Generally due to constraints around processing micro controllers can support only 1-4 TLS sessions
E) There is a discipline called lightweight cryptography which addresses some of these challenges and they have some interesting protocols
Andrei
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.