Hey guys very new to let's encrypt and SSL in general. But I have a server that automatically does let's encrypt certificate renewals every week. But I am curious does this mean that I'll have to load new ca-certs onto my client at some point? Or is this not involved in the renewal process?
I am a little confused about how the renewal process affects the keys and certificates held by the client.
Hi @Feynman137
Does that mean it re-issues certs (or that it checks for renewals) every week?
Which ACME client do you use to manage your certs?
CA certs are supposed to be maintained by the O/S maintainer.
What O/S (and version) do your clients use?
Which client?
["keys" are generally held by "the server" not "the client"]
I am following this short tutorial link this is really all I know about the SSL portion. But let me try to answer the questions.
For the first question
It mentions: "The certificates are only good for 3 months, so you’ll want to setup automatic certificate renewals. It’s easy by typing crontab -e and adding this at the end of the file"
For the second question
The client is just a little PCB that I made with a cellular modem. So doesn't really have an operating system. I apologize if by O/S you meant something else.
For the third question:
My set-up right now has just one client. My server is a digital ocean VM that my client connects via port 8883 and publishes data.
The client only needs to trust the root CA that validates the server's cert.
That root CA won't expire until 2035.
Certbot usually installs a cron job on install.
Let's see if you have a cert and if cron was already setup.
Please show the output of:
certbot certificates
crontab -l
Here is the information requested. It seems to be that there is a renewal task in place.
Found the following certs:
Certificate Name: my DNS address
Domains: my DNS address
Expiry Date: 2022-02-20 01:29:11+00:00 (VALID: 72 days)
Certificate Path: /etc/letsencrypt/live/my DNS address/fullchain.pem
Private Key Path: /etc/letsencrypt/live/my DNS address/privkey.pem
root@broker1:/# crontab -l
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
*/5 * * * * ~/duckdns/duck.sh >/dev/null 2>&1
# LetsEncrypt renewals every Monday at 2:30 am
30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log
I suppose that by "DNS address" you mean a real FQDN [as certbot can't (yet) get issued a cert for an IP address].
As you can see, it was renewed less than 3 weeks ago.
The cron job needs a little love.
As the text show, it's set up to run only once a week - it should run twice a day.
Try adjusting it to:
30 2,14 * * * /usr/bin/certbot renew
And there is no need to pipe the output to the file /var/log/le-renew.log; The default action is to write all logs to /var/log/letsencrypt/letsencrypt.log
And can you clarify a bit more what you mean by "load new ca-certs onto my client" and "doesn't really have an operating system"? Did you need to build your own custom trust store (a list of trusted root certificates) for it? If so, then yes there are several practices you should be using to ensure that your system continues to work as roots change, and definitely takes some care.
So it sounds like I will not need to be loading new ca-certs onto the client anytime soon. Which is a relief. Let me attempt to answer the questions.
Right there is an actual DNS address here not just an IP. The address ends with .duckdns.org
I can do this no problem.
The client device is a cellular modem that receives AT commands from an MCU so I have to flash/upload the cacert into the UFS of the modem using a usb connection. After this I execute another AT command to tell the modem the filepath of the cacert in its UFS.
I don't know enough about this stuff, but the modem just has firmware loaded on it nothing else.
What software is performing the TLS connection from the modem? Is it part of the firmware?
It's possible that the firmware contains a trust store (list of root certificates that it will accept), unless you're using some other kind of library on top of it (like curl or openssl or something).
What we're trying to get at, is did you put together the certificates in that cacert file? Or did you get it from somewhere else?
If you did it, and all that it has in it is the "ISRG Root X1" certificate, then that should be good for "a while". But let me go over some of the ways that it might no longer be the root you need:
Now, I don't know as any of those are especially likely for your use case. And if this is a device that's "sitting on your desk" or the like and relatively easy to update with physical access, then it may make sense to just keep the one root in there and just plan to update it if you need to. But if this is a device that's out "in the field" somewhere, and especially if it's relying on this secure connection in order to get updates at all, then you want to do a bit more contingency planning. You'd probably want at least two different CAs, to improve the likelihood that at least one of them was something you could be sure to get a certificate for in the future. You may even want to create your own CA to put as a root on the device, even if it's just as a "backup plan". A Let's Encrypt engineer replied to a similar question here with some recommended software for making your own CA as a backup for this sort of embedded systems scenario.
And whatever you do, ensure that it's only root certificates in the trust store, and not the intermediates or leaf certificates. Those can (and do) change all the time. Intermediates should be sent by the server as part of the TLS handshake, and the client should only need the root in order to validate the connection.
@petercooperjr's got it exactly right. If this is on your desk and easy to update, don't worry about it. If this is going to be put somewhere hard to reach, you'll need to do some more serious thinking about how to send it updates - including especially updates to the root store. If that's the case you are best off making your own root, which isn't as hard as it sounds. We can give you some advice there if needed.
I believe this is in the firmware. This app note has an intro and includes some of the more technical details. link
Below are the exact steps that I followed on my server. The device in question is a client to the server that I am doing the certbot install on. This is an excerpt from mqtt tutorial although I am not doing a weather station it is still relevant to my approach.
But I followed these steps and then went to
/etc/letsencrypt/live/mydns.duckdns.org# ls
README cert.pem chain.pem fullchain.pem privkey.pem
extracted the file chain.pem and uploaded and saved it as ca-cert to my client device. And now I am wondering will I ever need to renew this ca-cert?
@petercooperjr thank you for your detailed list. I am currently reading through and trying to digest. As I mentioned I've got a lot to learn here so it takes some time for me. But I can say with confidence that these devices will not be sitting on my desk and will be very remote. I believe this also ties into what @jsha is saying.
Great, that's really useful to be clear about! Given that, it's super important to have a good plan for how you will update these in the field. That's a bigger problem than certificates and is particularly hard for small devices, where there's often not enough storage space to hold a full copy of the OS. But it's necessary nonetheless, since bugs and vulnerabilities inevitably crop up post-deployment.
Once you've got that figured out, I recommend making your own CA to issue certificates for the server. You can generate one very easily with GitHub - jsha/minica: minica is a small, simple CA intended for use in situations where the CA operator also operates each host where a certificate will be used.. You load the resulting minica.pem (the root certificate aka root certificate) onto the devices, and keep a copy for yourself to generate future certificates.
The reason for making your own CA: public CAs (like Let's Encrypt) are subject to various rules that may require us to revoke your certificates for things like key compromise or problems with the certificates themselves. If that caused your devices to no longer be able to phone home, it would be a problem for you - and one we wouldn't be able to help you get out of. By having your own CA, just for your one server, you control your own destiny.
RED ALERT! That's completely wrong! 
That chain.pem is for your server. It has nothing to do with setting up a trust store for your client. The ISRG Root X1 that's the root certificate for Let's Encrypt is at https://letsencrypt.org/certs/isrgrootx1.pem and that should be what's in your client's trust store in order to allow you to connect to Let's Encrypt-secured servers.
But as we're saying, configuring a good trust store for a device is complicated and requires a lot of thought, and an amateur can easily make poor choices. Mozilla/Google/Apple/Microsoft/etc. put a lot of effort into building the list of CAs that their systems trust by default, and while your use case may not need quite that level of effort if end-users aren't trusting your device to connect to random sites on the web, you probably need some level of effort.
The client is using it for server authentication. According to this post Loading SSL keys onto client, which ones? - Help - Let's Encrypt Community Support (letsencrypt.org)
I apologize if this wasn't made clear earlier. Is this not correct?
Thank you very much I will read through this as this is something I need to address. To your earlier point I haven't a clue how I will update these while they are in the field. The only thing in my favor here is that the device isn't doing a whole lot. So firmware is pretty simple.
As @jsha said in that thread, everything certbot gives is only for the server. The client, in order to ensure that it's connecting to the server that it thinks it is, trusts some set of CAs to make assertions that servers are who they say they are. So it loads those CAs' root certificates onto its trust store (those are the cacerts you refer to), and then when a server presents its certificate and chain, the client can verify that the certificate was in fact signed by one of those CAs.
Usually operating systems take care of coming up with a list of trusted CAs for you (one of the most important jobs of an operating system that almost none of the users realize). But if you're building your own operating system then you can either steal one from one of the major vendors (like use your favorite Linux distribution's ca-certificates package, though be aware that it's usually based on Mozilla's list and Mozilla wants people to be clear exactly what their list is intended for), assuming that your system supports having that many trusted roots, or go through the effort of building your own. But as we're saying, either way you need to figure out how you'll regularly update it, as the roots that you should trust do change over time. If it turns out that Let's Encrypt is actually secretly run by a cabal that would accept large amounts of money to issue a certificate to somebody that they shouldn't, then you need to plan how you would switch to some other CA.
(Note: There is no cabal.)
(from Loading SSL keys onto client, which ones?):
As with most tricky things in computers, it depends. 
If you choose to go the "be your own CA" route: Download and run GitHub - jsha/minica: minica is a small, simple CA intended for use in situations where the CA operator also operates each host where a certificate will be used. with --domains <your server name>. Then use the resulting minica.pem as ca-cert.pem. Make careful backups of all the generated files - without them you won't be able to make new certificates when you need them. Install <your server name>/cert.pem and <your server name>/key.pem on your server. And be prepared to re-run minica and install the new certs on your server a few months the old ones expire.
If you choose to go the "trust external CAs (like Let's Encrypt)" route: Make a plan for updating the firmware on your device, or at least updating ca-cert.pem. Before that plan is made, figuring out what to put in ca-cert.pem is premature.
@jsha thank you very much for this. I don't want to continue to ask questions and give the appearance that I am not reading on my own end, but I felt this question was necessary. If I do go the minica route, it sounds like my server will have the files: cert.pem and key.pem while my client will have the file ca-cert.pem. But where will I be doing the minica installation as detailed on the github page, could it be any computer?
Also wanted to mention I am reading through this tutorial link which is doing almost exactly what I am trying to do. MQTT protocol over SSL that is. And they accomplish what we are discussing using openSSL instead of minica
for public certificate you can download newest from curl - Extract CA Certs from Mozilla
disclaimer: this isn't direct from Mozilla but from curl project, I don't vat it's identical with real NSS trust store.
add your own root certificate's pem at the end of file
Yes, any computer that you trust enough and whose data will be reliably available enough for the life of your application. Using a computer for a CA service, even through minica, somewhat increases the importance of keeping it secure and having reliable and accessible backups.