Certbot can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing the certificate.
certbot: error: argument -d/--domains/--domain: expected one argument
Even if you don't get an error after fixing this command, it still won't work to do what you expect for renewals. The --manual authenticator will completely refuse to run non-interactively, including from cron (it detect whether its input is a terminal or not). The exception to this is if you add a hook script which can make the DNS changes required.
One thing you might have missed in trying to use this command for automated renewal is that the token that you have to post in your DNS zone is different every time you renew, so just leaving it in place and running a Certbot renewal command can't succeed. Your command (or you) will actually have to do something to publish the new token in DNS every time.
Certbot can work with various DNS provider APIs in order to make these changes non-interactively from software, but you have to know if your DNS provider offers an API, and you have to write the authentication hook script yourself, or else find an existing Certbot plugin for your particular DNS provider's API.
The --manual-auth-hook option requires an extra parameter which is the name of a script or program to run in order to complete certificate authority challenges. This is described in more detail at
Just adding --manual-auth-hook without specifying such a script won't work; it isn't the correct syntax.
But yes, you would need to have such a script in order to automate certificate renewal using the Let's Encrypt DNS challenge.
This is a certificate authority behavior that many people find confusing.
When a particular Let's Encrypt account successfully completes a challenge to prove control over a name, the certificate authority remembers this fact for a period of time. This allows certificates to be reissued without completing the challenge. I don't remember the exact amount of time that Let's Encrypt caches authorizations, but I believe it is somewhere around one week.
Unfortunately, that's not long enough to benefit from this for scheduled certificate renewals. In order to maintain a valid Let's Encrypt certificate on a site, you'll need to complete a new challenge to re-verify your control over each name in the certificate, at least once every 90 days. This new challenge always contains a new token, which must be posted.
If you wait for a few weeks and then try issuing your certificate again with wacs.exe, you'll also see that it requires posting a new token. The difference it isn't about the operating system that your client runs on, but rather about the amount of time between certificate issuance attempts.
The fact that authorizations eventually expire (in a much shorter time than the lifetime of the certificate) is why Certbot expects you to provide the --manual-auth-hook capable of updating DNS records, if you want it to renew certificates from a cron job or any other unattended or automated environment.
Well, I would be interested in figuring out what WACS is doing differently here! However, I'm very confident that Let's Encrypt is requiring new tokens from the CA side for certificate renewals—this issue has been discussed very often on this forum, including by some of the developers who implemented the CA's authorization logic.
Let's Encrypt caches challenge authentications for 30 days, meaning that if you request a certificate that includes any given domain name using an ACME account that has already had a successful challenge authentication of some type (e.g. dns-01, http-01) for that domain name within the last 30 days, you will not be required to fulfill a challenge AT ALL for that domain name. Thus, of course you wouldn't need to update any DNS records for that domain name.
Your current certificate isn't a wildcard, so you probably don't need either --manual or --preferred-challenges=dns; is there some reason that you concluded that you do need these?
For example, maybe you could use --standalone or --webroot in Certbot instead?
Edit: I see that the tutorial you followed specifically says to use --preferred-challenges dns and --manual, but I don't know why it gives that advice. I can't think of any benefit to this method for most users!
It might be that you used certbot --nginx on the machine with nginx? That literally uses nginx as part of the certificate request process.
If you have a machine with no web server, the best Certbot option is certbot --standalone.
All of the Certbot authenticator plugins (described in the user guide that I link to) use different strategies to satisfy the CA's challenges, and different ones are appropriate in different environments.
Keep in mind that a --post-hook will be run after each time you try to acquire a new certificate, regardless of whether you actually acquire one. I suspect that you really want a --deploy-hook that will only be run after each time you actually acquire a new certificate.
The main difference is that --nginx will reload nginx for you after successfully acquiring a new certificate (via nginx -s reload). Obviously this is not needed with --standalone, which spins up a temporary webserver that runs just long enough to serve the challenge file(s).
Saving debug log to /var/log/letsencrypt/letsencrypt.log
The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError("Could not find a usable 'nginx' binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.",)