Move cert to remote share on issuance

I am running on Windows Server 2016. I am using the latest version from the beta installer.

I’ve written a renewal-hook and placed it in the deploy folder at C:\Certbot\renewal-hooks\deploy\convert.bat and verified it works when forcing a renewal. It takes the pem files and converts as necessary and places in the network share. Great!

Now, I thought from Windows assume identity that this would also happen the first time I requested the certificate using certbot certonly -n --webroot --agree-tos --email -d -w '//my/remote/share$' but the deploy hook doesn’t run.

Is there any option to run my hook when requesting the certificate the first time?

1 Like

Try adding: --deploy-hook "c:\Certbot\renewal-hooks\deploy\convert.bat"

certbot certonly -n --webroot --agree-tos --email -d -w '//my/remote/share$' --deploy-hook "c:\Certbot\renewal-hooks\deploy\convert.bat"
1 Like

Does it not get invoked at all, or does it get invoked but fail for some reason?

You should be able to see in C:\Certbot\logs\ whether Certbot tried to run the hook.


I just checked the logs - in my forced renewal I get a line about the deploy hook running and the output.

I have no lines with “hook” in the next log where I request a new certificate with the command provided above.

1 Like

This ran the hook.

The folder solution is much more practical and user friendly - should the scripts in the folder be running on the initial request?

1 Like

I would think that it should.
Perhaps this is a bug…
I’m not familiar with certbot for Windows.

1 Like

Agreed, that does not seem ideal. The documentation calls it out:

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

but I suspect many users (myself included) would overlook that detail.

There is further commentary of why it works that way and why it’s hard to change here:


You could emulate the behavior you want with /etc/letsencrypt/cli.ini:

deploy-hook = /path/to/hook

Though I’m not sure whether it will have unintended consequences for other Certbot commands. Doesn’t seem to, but I’m not an expert in how Certbot’s CLI arguments get processed.

1 Like

The difference being that pre and post will run regardless when trying to renew, deploy will only run on a successful renewal?

1 Like

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