I'm putting this under feature request because I think this is expected behavior as it is but with a small change can be made useful.
My company uses a DNS provider that doesn't have any form of api so requires records to be updated manually. I created a wildcard certificate by manually updating the _acme-challenge TXT record, but couldn't find a similar way to renew the cert because the manual-auth-hook script can't echo to the console when running a certbot renew command. The auth-hook script can be very simple IE:
#!/bin/bash
CREATE_DOMAIN="_acme-challenge.$CERTBOT_DOMAIN"
echo "Set txt record $CREATE_DOMAIN to $CERTBOT_VALIDATION"
echo "Press enter when done"
read
The problem is the text is not printed to the console until after the script exits so I can't see what needs to be updated in the dns until it's too late. To work around this I replaced the echo with wall and was able to update the record manually.
Is there a better way that is already built into certbot or could the execution of the auth-hook script be changed to allow the text to be passed through before the script exits?
While certbot is not owned or maintained by Let's Encrypt (the EFF owns and maintains it), there is some chance that this request will be seen here by the EFF. To increase that chance, I recommend making this suggestion directly to the EFF.
And just to be sure: you absolutely need to use the dns-01 challenge? What's preventing you from using the http-01 (or tls-alpn-01 with a different ACME client)?
Invoking certbot with --debug-challenges will do what you want.
--debug-challenges After setting up challenges, wait for user input
before submitting to CA. When used in combination with
the -v option, the challenge URLs or FQDNs and their
expected return values are shown. (default: False)
I do strongly suggest automating things though. I recommend acme-dns as well, but you can delegate your _acme-challenge records onto any secondary DNS provider of your choosing (that supports API). These DNS records only exist to answer challenges and can be on any domain.
The Certbot renew command is intended for automated operation. Usually run by a cronjob or systemd timer. These don't provide for manual interaction.
It is not the only way to "renew" a cert though. Just re-issue your original command. This will get a fresh cert the same as Certbot's renew command. We often say "renew" a cert just to mean get a fresh cert with the same domain name(s) as the previous one. It can be a confusing with the same word used in different contexts.
If you don't use Certbot renew command for any other certs just disable the cronjob and / or systemd timer.
If you have a mix of Certbot "auto-renew" and manual ones use the --no-autorenew setting when getting the cert so that the renew command does not process it. From the Certbot docs:
--no-autorenew Disable auto renewal of certificates. (default: False)
Perhaps it would have been clearer if Certbot's renew command was instead RenewAll or AutoRenew or something but ...
