CERTBOT_DOMAIN not passed to authenticate.sh or cleanup.sh

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
jeffsani.com, jeffsani.com
I ran this command:
certbot renew --force-renewal --manual --manual-auth-hook /etc/letsencrypt/renewal-hooks/pre/authenticate.sh --deploy-hook /etc/letsencrypt/renewal-hooks/deploy/deploy.sh --manual-cleanup-hook /etc/letsencrypt/renewal-hooks/post/cleanup.sh --server https://acme-staging-v02.api.letsencrypt.org/directory --email webadmin@jeffsani.com --manual-public-ip-logging-ok

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/jeffsani.com.conf

Plugins selected: Authenticator manual, Installer None
Running pre-hook command: /etc/letsencrypt/renewal-hooks/pre/authenticate.sh
Output from authenticate.sh:
Now creating authentication DNS records for from list:
Stripping leading *. if exists
Making call to GoDaddy API for domain:
{“code”:“INVALID_BODY”,“message”:“Request body contains no valid fields”}
TXT records created
Going to sleep for 60 sec to let DNS changes propagate

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

certbot 0.31.0

indent preformatted text by 4 spaces

echo “Now creating authentication DNS records for $CERTBOT_DOMAIN from list: $CERTBOT_ALL_DOMAINS”

As you can see the echo does not contain the variables. Does this have to do with the fact I am using staging?

There is a confusion about the types of hooks here.

/etc/letsencrypt/renewal-hooks/{pre,post} are approximately identical to --pre-hook and --post-hook, respectively (except that the ones in the directory only get invoked at renewal). These are not authentication hooks! They are just for making Certbot do an arbitrary task before and after any work gets done.

--manual-auth-hook and --manual-cleanup-hook, which are authentication hooks, have no equivalent within the /etc/letsencrypt/renewal-hooks/ directory.

With the command you have posted, /etc/letsencrypt/renewal-hooks/pre/authenticate.sh gets invoked twice:

  • Once in the context of “run this before Certbot does anything”
  • Once in the context of “authenticate this domain”

That’s why you would not see $CERTBOT_DOMAIN in the first invocation.

My suggestion: take the authentication and cleanup hook out of the /etc/letsencrypt/renewal-hooks/ directory.

1 Like

Well that explains my confusion. I will try your suggestion. What about deploy scripts?

Deploy hooks are separate once again, with their own set of environment variables:

  --deploy-hook DEPLOY_HOOK
  Command to be run in a shell once for each successfully issued certificate. For
  this command, the shell variable $RENEWED_LINEAGE will point to the config live
  subdirectory (for example, "/etc/letsencrypt/live/example.com") containing the
  new certificates and keys; the shell variable $RENEWED_DOMAINS will contain a
  space-delimited list of renewed certificate domains (for example, "example.com
  www.example.com" (default: None)

In general:

  • Pre/post-hooks: used to stop/start services, modify firewall rules, etc, which would conflict with Certbot’s authentication methods.
  • Manual authentication hooks: Performs the actual deployment of the challenge resource ($CERTBOT_TOKEN) to $CERTBOT_DOMAIN.
  • Deploy hooks: used to force servers to reload the renewed certificate from /etc/letsencrypt/live/$RENEWED_LINEAGE/ off disk, or to copy or transform it to another location.

I would be careful about using the /etc/letsencrypt/renewal-hooks/ directory at all. Using the command line flags and storing the hooks elsewhere, is more predictable and less confusing.