Certbot renew for cockpit web interface

[oDn]

Hi everyone,

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.

Any advice would be greatly appreciated!

Thanks.

[griffin]

Welcome to the Let's Encrypt Community

@oDn

Should I be using a deploy-hook and a custom script to ensure that the certificate is properly renewed using certbot-renew.timer ?

Yep. Be sure to also reload your webserver once the new certificate is properly installed.

[oDn]

Thanks for the warm welcome and the swift reply!

I can't seem to find much detailed information about how to use a deploy-hook... Can it be configured for a specific certificate or is it global?

[rg305]

--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.

[griffin]

Apache reload example:

--deploy-hook "sudo apachectl -k graceful"

Nginx reload example:

--deploy-hook "sudo nginx -s reload"

[oDn]

Right. Thank you both for your feedback.

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 ?

[griffin]

You don't need to use --deploy-hook in that case.

Maybe this will help:

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.

User Guide — Certbot 1.11.0.dev0 documentation

[oDn]

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...

[rg305]

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.

[schoen]

@rg305

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.)

[oDn]

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...

[rg305]

@oDn

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.

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.

@oDn

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.

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.

[oDn]

Thanks for the reply!

@rg305

You can use the command line to automatically and properly "create" those entries; as certbot will learn from a successful renewal.

So forcing a renewal with the proper parameters will update the configuration file ? I was only running dry runs to avoid spamming the service.

@rg305

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.

When running renewal dry runs with the deploy_hook label, the script was never executed so it seems they aren't interchangeable.

[rg305]

@oDn

So forcing a renewal with the proper parameters will update the configuration file ?

Yes.

@oDn

When running renewal dry runs

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).

[oDn]

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.

[rg305]

@oDn

There is no mention of this in the output when using the deploy_hook label.

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.

[oDn]

@"rg305

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.

Yes, this is perfectly clear. Thank you.

[_az]

@oDn

The options that should go in the configuration file in /etc/letsencrypt/renewal aren't really documented anywhere.

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.

@oDn

I would have expected a deploy_hook entry. I guess it's due to renew_hook not being completely deprecated yet...

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.

[oDn]

Thanks @_az for clearing things up!

[Osiris]

@_az

But it's understandable, since there's no other way to modify those parameters without re-issuing the certificate.

Isn't there an issue on the certbot Github page for making certificate management more easily? Asking for a friend