I was curious to know what the best way would be to manage my certificate renewal for the cockpit web interface.
So far, I've successfully managed to create my certificate with certbot but I've had to copy the files manually to /etc/cockpit/ws-certs.d/ and fix the permissions on the files to get everything working properly.
Should I be using a deploy-hook and a custom script to ensure that the certificate is properly renewed using certbot-renew.timer ?
I'm currently using certbot 1.12.0 on Fedora Server 33.
--deploy-hook can be used for a specific cert.
On your next successful cert renewal, if you added the --deploy-hook parameter, it will be learned by certbot and then reused on subsequent renewals.
So I can create a script in /etc/letsencrypt/renewal-hooks/deploy/ and renew my certificate with certbot and the --deploy-hook option and then expect that script to run for all further deployments ?
Does putting a script in that directory mean I can use just the name of the script and not the full path to it ?
You can also specify hooks by placing files in subdirectories of Certbot’s configuration directory. Assuming your configuration directory is /etc/letsencrypt, any executable files found in /etc/letsencrypt/renewal-hooks/pre, /etc/letsencrypt/renewal-hooks/deploy, and /etc/letsencrypt/renewal-hooks/post will be run as pre, deploy, and post hooks respectively when any certificate is renewed with the renew subcommand. These hooks are run in alphabetical order and are not run for other subcommands. (The order the hooks are run is determined by the byte value of the characters in their filenames and is not dependent on your locale.)
Hooks specified in the command line, configuration file, or renewal configuration files are run as usual after running all hooks in these directories. One minor exception to this is if a hook specified elsewhere is simply the path to an executable file in the hook directory of the same type (e.g. your pre-hook is the path to an executable in /etc/letsencrypt/renewal-hooks/pre), the file is not run a second time. You can stop Certbot from automatically running executables found in these directories by including --no-directory-hooks on the command line.
Is there a way of creating a script in /etc/letsencrypt/renewal-hooks/deploy/ and make it specific to a certificate renewal? It seems this would be applied globally...
That location would be applied globally.
You need to include the specific renewal script within the specific cert renewal.
That will teach certbot to do that script when it renews that cert.
(It saves this information in the file under /etc/letsencrypt/renewal describing that individual certificate, which is checked when autorenewing that certificate.)
OK, after having had to configure a plugin to be able to use a DNS challenge (cockpit listens on port 9090), I think I've managed to get everything to work.
Is there a way to modify the renewal options for a given domain without using the certbot certonly command ?
The options that should go in the configuration file in /etc/letsencrypt/renewal aren't really documented anywhere.
Also, I've noticed that when using --deploy-hook with certbot certonly, it creates a renew_hook entry in the configuration file. I would have expected a deploy_hook entry. I guess it's due to renew_hook not being completely deprecated yet...
That is the right place.
Yes, documentation is lacking.
You can use the command line to automatically and properly "create" those entries; as certbot will learn from a successful renewal.
Technically an insignificant label there.
Since the command will only execute when that individual cert is renewed and only after it has been renewed, both labels (in that context) will produce the exact same end result.
Dry runs won't change/save anything, nor actually renew anything, so it makes sense if it doesn't run the deploy_hook (nothing was renewed nor deployed).
Actually, during dry runs and when using the renew_hook label the output specifically mentions that the script is skipped. There is no mention of this in the output when using the deploy_hook label.
The output does use the term "deploy" though: "Dry run: skipping deploy hook command: [...]"
So basically there's an inconsistency between the label name and what the output says.
Then it is missing, let me bring in some folks that might know more about that and how to correct it (@certbot-devs).
In the meantime, you must understand that dry runs won't do anything at all - other than just the test of obtaining a cert. Using that will make no permanent change to anything/anywhere.
[quote="rg305, post:16, topic:146024]
In the meantime, you must understand that dry runs won't do anything at all - other than just the test of obtaining a cert. Using that will make no permanent change to anything/anywhere.
[/quote]
Yes. These files are not part of Certbot's public interface, i.e. users aren't really meant to mess with them. But it's understandable, since there's no other way to modify those parameters without re-issuing the certificate.
Yes, long ago the CLI flag --renew-hook was deprecated and superseded by --deploy-hook. The difference is that --deploy-hook gets invoked on the initial issuance, not only during renewals.
However, internally in Certbot and in the renewal parameters file, that field continued to be named renew_hook, to avoid breaking things.
That's why the CLI flag and the renewal parameters file don't quite match in the case of --deploy-hook.
Asking for a friend 