How do I make sure? -- a zombie client self-check procedure to perform regularly, or even a new certbot function!

Feature Requests
1

hi,

I have just read about the zombie client problem (link), and the preventive functions.

I know that I have domains that time after time don't get renewed and to be honest I also seem to remember error messages (email), which I would quickly identify like "oh, it's because it doesn't exist now", and I'd move on.

Out of curiosity, I just looked at my domain list that the apache certbot would display...
and I saw several domain names which I don't have the DNS service linked to...

I'm not negligent... I had just thought that I'd have those domains back sooner or later...
I would normally issue a2dissite for domains that are not in "use" (in my ownership), hoping that certbot will realize the situation... But I might have been negligent enough to forget about this little task, too....

Anyway, now I promise I'll make sure not to waste any amount of letsencryp's resources...
I will regularly run certbot certificates, copy the result check for "invalid: expired!" statuses and delete the zombie certificate whom I had created :frowning:

suggestion:
#1 a self-checking task list would be great... which people could refer to...

#2 a function could be created, perhaps extending certbot certificates with options like stat / info (meaning a brief info about okay / not okay...
and problems ... which would list the problematic certificates only...

these functions could make it easy to get a quick picture of the state of things...
which would give an easy but regular "job" for the site admins... which could be a great thing, unlike getting used to having to do nothing cause certbot is sooo intuitive and perfect :slight_smile:

sorry if this topic already exists :slight_smile:

Peter

2

First, this sounds more like a feature request for Certbot itself. You'd be better off making this suggestion on the EFF's github for Certbot: GitHub - certbot/certbot: Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol. This Feature Requests section is more for Let's Encrypt features or the LE website.

That said, wouldn't something like below be enough to quickly identify issues? I don't have an expired cert to check so adjust the grep search term(s) accordingly

sudo certbot certificates 2>&1 | grep -E 'VALID|EXPIRED' | grep -v 'Saving'

You could use standard bash for parsing and other selective actions based on grep results

5 Likes
3

I have expired certs on some test environments.

Starting with @MikeMcQ's commend, this edit should identify the problematic ones for you:

sudo certbot certificates 2>&1 | grep -E 'INVALID' -B4 -A2

The expiry line of certbot certificates will show something like:

Expiry Date: 2025-06-09 19:49:28+00:00 (INVALID: EXPIRED)
Expiry Date: 2025-06-09 19:49:23+00:00 (INVALID: TEST_CERT, EXPIRED)

using -B4 will include the preceding 4 lines, -A2 includes the 2 after, so the output will contain the full data for that record:

--
  Certificate Name: dev.example.com
    Serial Number: 0123456789abcdef0123456789abcdef0123456789abcdef
    Key Type: RSA
    Domains: dev.example.com
    Expiry Date: 2025-06-09 19:49:23+00:00 (INVALID: TEST_CERT, EXPIRED)
    Certificate Path: /path/to/fullchain.pem
    Private Key Path: /path/to/privkey.pem
--
  Certificate Name: dev2.example.com
    Serial Number: 0123456789abcdef0123456789abcdef0123456789abcdef
    Key Type: RSA
    Domains: dev2.example.com
    Expiry Date: 2025-06-09 19:49:23+00:00 (INVALID: EXPIRED)
    Certificate Path: /path/to/fullchain.pem
    Private Key Path: /path/to/privkey.pem
--

IMHO, doing a feature request for this is a very good idea. I do like the idea of certbot problems.

This is just a quick way to see the info you need, today!

6 Likes
4

You might also consider a monitoring service. That will let you know of cert expirations before they occur. Several are mentioned below. Let's Encrypt announced in Jan they would stop emailing expiration notices. And, since that has now ended (see blog) these may be helpful.

3 Likes
5

For people interested in monitoring renewal failures (rather than just cert expiry) you are welcome to try out Certify Management Hub and Certify Management Agent - it's still in development but might work for you.

The hub provides a UI which can be hosted in docker or run as a service directly and can provide centralised cert management or just be used for monitoring.

The agent is a systemd service that can either perform cert renewal tasks on that instance or can be used to monitor 3rd party acme clients (currently Certbot, acme.sh, win-acme, simple-acme and Posh-ACME). Again that could run either directly or in docker. It's a little heavy on RAM currently but that should be reduced in future updates, the monitoring agent is currently very new and I don't believe anyone has actually tried it in production yet.

You can configure paths in the hub UI under Settings > General > External Cert Managers with the target agent instance selected.

2 Likes
6

thank you, Mike!

1 Like
7

thank you! :slight_smile:

For me, your search code (as well as Mike's) is a perfect solution...
But of course, the point is to offer a good method for mostly everyone...
I'm sure many would choose webprofusion's suggestions, headless or with a head :slight_smile:

8

Thank you for your suggestion.
Personally, I don't like the "capitalist" model of building premium or freemium services on free stuff (software / services)...

Even building services (free or not free), for comfort's sake, upon a service, seems to me as a waste of resources...
Reducing the bot traffic, for example, is an environmental-conscious issue these days...
But thank you!

9

It would also be useful if certbot (and most ACME clients really) wrote the last attempted result [and count of sequential failures] to the renewal .conf or equivalent, rather than just using free text logging, because then you could see a summary of failing renewals before they expire.

1 Like
10

I mean, if I were able to only add one thing to certbot to help with zombie clients, it'd be to change certbot so that if it consistently fails to renew for an extended time (3 to 6 months, I guess), it gives up until a user specifically asks for renewal, and doesn't keep trying forever. (Or maybe only tries once a week or once a month, instead of twice a day, at that point.)

3 Likes
11

You can follow Certbot progress at their Github here:

3 Likes