Most active commenters
  • johnisgood(3)

←back to thread

181 points zdw | 11 comments | | HN request time: 1.298s | source | bottom
1. scrapheap ◴[] No.44421396[source]
This makes sense to me. You should never rely on your CA to let you know that a certificate is due to expire soon, you should have your own monitoring in place that actively checks this for you.
replies(2): >>44421753 #>>44421782 #
2. kassner ◴[] No.44421753[source]
I do agree with you, and setting up your own monitoring is key. I have that.

Yet it was still valuable to find those that fell through the cracks. At work, the emails prevented a couple of outages by expired cert, because a dev that left was renewing them by hand and we only found out when they left and the catch-all started to bubble them up to support.

Things fall through the cracks, or people are in a pinch and just forget to add the cert to the in-house monitoring system. The emails were a wonderful failsafe.

I wish I could just query LE to tell me all existing certain where the account is under my domain name. Extremely helpful to assemble a SBOM.

3. bo1024 ◴[] No.44421782[source]
As a hobbyist without a lot of time for sysadmin, it would be nice if basic email monitoring was a standard package (apt install letsencrypt-monitors or something).
replies(3): >>44421841 #>>44422380 #>>44423233 #
4. bravesoul2 ◴[] No.44421841[source]
Use one of the myriad uptime monitoring services.
5. johnisgood ◴[] No.44422380[source]
Just use certbot. It automatically sets up a scheduled task to renew your SSL/TLS certificates in the background, typically using a systemd timer that runs twice a day. I do not know why people using LetsEncrypt would not set up certbot along with it, that is how I do it. Some nginx config + certbot.
replies(2): >>44422649 #>>44427499 #
6. Walf ◴[] No.44422649{3}[source]
Maybe the situation's improved, but I found certbot from system package managers would diverge from latest version, sometimes significantly, like support for DNS challenge APIs breaking. I switched to ‘acme.sh’ for most machines and haven't looked back. It no longer has Let's Encrypt as its default issuer, but you can set it back to LE with one config command.
replies(1): >>44422664 #
7. johnisgood ◴[] No.44422664{4}[source]
I was going to mention acme.sh, too. certbot and acme.sh are two popular methods.

That said, I never had issues with certbot on Arch Linux, and I have been using it for a really long time.

Since Arch Linux is bleeding-edge, it does not diverge from latest version. :D

8. jeroenhd ◴[] No.44423233[source]
You can get pretty close to this by (1) setting up certbot and (2) configuring your system to actually send emails if cron jobs fail.

I can see the use in a tool that will scan all certificates configured in local web servers and monitors for close expiration dates, though. Not just Let's Encrypt, but also any other ACME accounts and certificate directories you may need. The biggest challenge would probably be dealing with encrypted certificate files, and after that getting email set up correctly. Nobody seems to have made it because it's so easy to script or add to a pre-existing monitoring system, so this could be a fun open source project. You probably can't use the letsencrypt brand name, though.

replies(1): >>44424941 #
9. JohnTHaller ◴[] No.44424941{3}[source]
Emails sent from most hosting servers won't actually get to your inbox, unfortunately.
10. bo1024 ◴[] No.44427499{3}[source]
I use certbot, but I don't think it will email me if something goes wrong.
replies(1): >>44438418 #
11. johnisgood ◴[] No.44438418{4}[source]
What would go wrong? I have been using LetsEncrypt (with certbot) for a really long time, and it never went wrong. Did it ever happen to you?