Cert was renewed by unknown job

Help
1

My domain is grepnik.default.grepnik.uk0.bigv.io, on my server running Debian buster.

I have the following command cronned twice a week at 02:53
/usr/bin/certbot renew
--deploy-hook /usr/local/bin/certbot_after_renew.sh
It last ran at that time yesterday and on 29/03.

certbot_after_renew.sh copies /etc/letsencrypt/live/grepnik.default.grepnik.uk0.bigv.io/privkey.pem to /etc/exim4/privkey.pem and adjusts permissions.

The cert was renewed on Mar 30 04:07. Syslog contains the following lines
Mar 30 03:59:56 grepnik systemd[1]: Starting Certbot...
Mar 30 04:07:04 grepnik systemd[1]: certbot.service: Succeeded.
Mar 30 04:07:04 grepnik systemd[1]: Started Certbot.
Nothing else happened around then that might be related.

It renewed the cert which was now due, and of course because it was not the cronned command the --deploy_hooks command wasn't run.

Can anyone suggest WHY certbot would have been started then by systemd?!

2 Likes
2

Hi,

First of all, can you check when did the systems service installed / last updated? You might be able to trace logs or recall who did it back at the time. @_az suggested in the post below that debian package include systems by default.

Also, the renew hook is supposed to be specified at domain/certificate level, and I remember you might need to do a --dry-run or --force in order to save your renewal hook into certificate config. (If it's not saved, and the renewal not triggered by your cron, the hook won't apply)

2 Likes
3

Debian includes a systemd timer with its Certbot package, assuming you installed it from apt.

I suggest keeping your deploy-hook in /etc/letsencrypt/cli.ini or as part of the certificate configuration when you initially create it. That way, behavior does not depend on the specific CLI invocation.

3 Likes
4

Question: isn't the deploy hook option saved in the renewal configuration file at renewal too? Or only when initially creating it?

3 Likes
5

Yes, that's right. Renewal will also update the flag.

Additionally, if the renew-hook = ... line is already present in /etc/letsencrypt/renewal/*.conf files, the CLI flag is redundant.

3 Likes
6

To my knowledge from working with --deploy-hook (and most any parameter), the renewal configuration is updated whenever a new certificate is acquired (or reinstalled via --keep). As @Osiris and I have directly experienced, using install does not necessarily have the same impact as --keep.

1 Like
7

@_az

Any idea why install doesn't update the renewal configuration for installation? Brad has yet to give me a straight answer.

1 Like
8

I'm not sure if you would accept this as a "why", but this is arguably my doing when I implemented Certbot's storage.py some years ago.

In storage.py there is a function called update_configuration, which saves a new renewal configuration on disk. This function is only ever called from save_successor, which saves a newly-obtained renewal certificate on disk. That function is only ever called from renew_cert, which attempts to obtain a new version of an existing cert.

Conclusion: there is no path in the code that tries to save a modified renewal configuration if a new cert wasn't obtained.

I think one the original motivation for this choice was to avoid saving a broken renewal configuration. That is, if we did a renewal with a new --webroot_path and it worked, it's OK and worthwhile to save that. But if the user randomly wants to change --webroot_path without trying a certificate issuance then we have no idea whether the changed version will or won't work. Therefore, we don't attempt save it in order not to risk breaking future noninteractive renewals.

3 Likes
9

So does that exclude a --deploy-hook being saved when --keep prevents certificate acquisition?

1 Like
10

Many thanks for all your replies. I really don't know enough to know what to do now. From my POV I'd guess I either want to stop the systemd timer or make sure that any invocation of certbot that results in a cert renewal also invokes the hook code. If anybody can explain what to do in terms that someone with no background in LetsEncrypt will understand, I'll gladly try it and report back.

2 Likes
11

I can't tell you from whence the renewal came, but I can explain how to accomplish what @_az has recommended if you want the help.

1 Like
12

Yes. I can see why that's counterintuitive. Essentially deployment options are being treated as a part of the process of acquiring a certificate (for configuration management purposes), but there's no reason that users would necessarily think of them that way.

2 Likes
13

I feel like certbot could be seamlessly refractored such that deployment-related updates to renewal configuration files are saved during deployment-related tasks. In essence, as I've been harping-on for a long time now, certbot could be refactored to have a definitive division between certonly acquisition and installation to avoid these counterintuitive behaviors.

1 Like
14

I would be happy if my certificate was automatic to renew so I could ignore it

16

Hi yes that would be great. What he said seemed to suggest that I can put a deploy hook statement into cli.ini. Would that run my hook script no matter how certbot was called?

Thanks in advance

2 Likes
17

First off, you'll want to check inside the .conf file in /etc/letsencrypt/renewal/yourcertname to see if a deployment hook is already listed.

If not (or you want to replace it), try this:

sudo certbot renew --cert-name yourcertname --deploy-hook /usr/local/bin/certbot_after_renew.sh --force-renewal

2 Likes
18

Thanks griffin. No, there's no deployment hook in the .conf file.
I tried the command you listed and it has renewed the cert and run the hook. Also I see the hook script has been added as renew_hook to the .conf file.
Does that mean that the hook code will be run whenever certbot renews the cert, however is gets called?
And should I now remove the --deploy-hook from the certbot cron job?
Many thanks to you and @_az

2 Likes
19

Yes and yes. :upside_down_face:

1 Like
20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.