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 foo@bar.com -d www.baz.com -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?

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

certbot certonly -n --webroot --agree-tos --email foo@bar.com -d www.baz.com -w '//my/remote/share$' --deploy-hook "c:\Certbot\renewal-hooks\deploy\convert.bat"

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.

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?

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

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: Hooks and certonly needs improvement · Issue #7737 · certbot/certbot · GitHub.

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.

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