Crontab: argument -d/--domains/--domain: expected one argument

Hello. I want renewal certificate from this tutorial: GitHub - gitpel/letsencrypt-routeros: Let's Encrypt certificates for RouterOS / Mikrotik

On the command line, this command completed successfully: certbot certonly --preferred-challenges=dns --manual -d $DOMAIN --manual-public-ip-logging-ok --post-hook /opt/letsencrypt-routeros/

But after add to cron:

  • 4 * * * certbot certonly --preferred-challenges=dns --manual -d $DOMAIN --manual-public-ip-logging-ok --post-hook /opt/letsencrypt-routeros/

I got error: usage:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

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

How i can fix it ?


Hi @Andrei9385

please read your error.

Looks like $DOMAIN isn't defined, so it's empty.


Thank you. I just replaced this key with domain


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.


schoen, could you explain in more detail?

  1. I need change:

certbot certonly --preferred-challenges=dns --manual -d --manual-public-ip-logging-ok --post-hook /opt/letsencrypt-routeros/


certbot certonly --preferred-challenges=dns --manual-auth-hook -d --manual-public-ip-logging-ok --post-hook /opt/letsencrypt-routeros/

  1. Should I resolve token issue in DNS?
  • Why doesn't the record need to be updated in Windows Server when renewing a certificate?

For example i'm use: wacs.exe --target manual --host,, --certificatestore My --installation iis,script --installationsiteid 1 --script "Scripts\ImportRDSFull.ps1" --scriptparameters "{CertThumbprint}"

Only on the first request did this command ask to create a record and did not ask any more.

TXT → _acme-challenge → B-hIpavWl1E123qud6xyTQweh0BfDbCU89MA_F2uFZQ


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.


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.

You're wrong. My certificate is updated without a DNS record update request

Also, this method is used on the mail server and this does not require updating the DNS record every time.


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.


Can someone advise technology to solve my problem?


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!


Unfortunately, I don't understand how to automate my process.

Why is there no problem on the web server(Like nginx) when issuing a new certificate and using the certbot renew or as with wacs in windows server.

Why is the problem only with the certificate on Linux without services.


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.


schoen, thank you !

After install nginx i'm use:

certbot --nginx -d --post-hook /opt/letsencrypt-routeros/

The certificate has been successfully issued.

There were no requests to make a DNS record or anything else.

What about domain ownership verification?

I just did a port forwarding:

External DNS server: "A" record (IP Address my router)

And on the router, forwarding port 80 to the internal address of the server with nginx

  • What command should I add to the cron? certbot certonly --standalone -d --manual-auth-hook /opt/letsencrypt-routeros/ ?

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.

Thus, this:

certbot --nginx -d --post-hook /opt/letsencrypt-routeros/

should probably be this:

certbot --nginx -d --deploy-hook /opt/letsencrypt-routeros/

When you installed certbot, it should have already created a cron job that runs something like this:

certbot renew -q

Thus, you shouldn't need to add a cron job at all.

You can test renewal by running:

certbot renew --dry-run

1 Like

griffin, thank you.

After add to cron:

certbot certonly --standalone -d --force-renewal --deploy-hook /opt/letsencrypt-routeros/ ( --force-renewal for test only )

I got certificate. Works great.

Will there be any difference between certbot --nginx and certbot certonly --standalone?


Not really.

  • If nginx is running, use --nginx
  • If nginx is not running, use --standalone

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).


griffin, can you help me ?

I gor error with nginx:

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.",)

certbot --nginx -d --deploy-hook /opt/letsencrypt-routeros/

1 Like

I do see nginx responding to HTTP requests.

  1. Have you made any significant changes regarding nginx?
  2. Please show the output of: nginx -T
  1. Nope. Only setup with command: apt install nginx
  2. root@certbot:~# nginx -Tnginx: the configuration file /etc/nginx/nginx.conf sy -
1 Like