Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA

Hello everyone!

My domain is:

I ran this command: certbot --apache

It produced this output:

root@server:~# certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Enter email address (used for urgent renewal and security notices) (Enter 'c' to

Please read the Terms of Service at You must
agree in order to register with the ACME server at
(A)gree/(C)ancel: A
Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

 - If you lose your account credentials, you can recover through
   e-mails sent to
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

My web server is (include version): Apache/2.4.25

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

My hosting provider, if applicable, is: Linode

I can login to a root shell on my machine: yes

I’m using a control panel to manage my site: no

Please see

Hello and thanks for the help, @schoen

I did find this and tried to enter the command but it resulted in a failure.

Did I perhaps botch the command when changing it for use with Apache2?

I see three possible problems with the command line there:

  • There is no --installer apache2; it’s just called --installer apache. (service apache2 stop and service apache2 start are probably correct, however.)
  • The \ -d is wrong unless there is a line break immediately after the \ character (otherwise, it puts a quoted space into the command which will confuse the argument parser).
  • If the space in --pos t-hook is really there in your command line, that’s a mistake.

Hopefully fixing these things will allow the command to run successfully.

Ok, I think I’ve modified it correctly. Will this work as a single-line command?

certbot --authenticator standalone --installer apache -d --pre-hook “service apache2 stop” --post-hook “service apache2 start”

And if I want the cert to work for both www and non, would I have to run this command again for the other or can it be modified to handle both?

Looks good, assuming that the quotes in your actual command are " and not characters.

Just add a second -d option, like -d -d, and then the certificate will cover both.

I sorted my quotes out and got it to run but I’ve got a new error:

root@server:/var/log/letsencrypt# certbot --authenticator standalone --installer apache -d -d --pre-hook "service apache2 stop" --post-hook "service apache2 start"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Running pre-hook command: service apache2 stop
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
Waiting for verification...
Cleaning up challenges
Running post-hook command: service apache2 start
Failed authorization procedure. (http-01): urn:acme:error:dns :: DNS problem: NXDOMAIN looking up A for

 - The following errors were reported by the server:

   Type:   None
   Detail: DNS problem: NXDOMAIN looking up A for

I’m not sure if this means that not enough time has passed from when I created the a record for the domains to resolve correctly for LE or if there’s another issue at play.

Any thoughts on the issue?

The www version of the name really doesn’t exist at your authoritative nameservers (for example NS2.101DOMAIN.COM). Are you sure that you’ve really created this record?

I successfully created the certs and it’s resolving properly. Thanks very much for all your help. I do have a question though.

Since the certbot application can not run without this special command, does this mean that I can’t benefit from the autorenewal feature? Will I have to run this command every 89 days?

I think that's a misapprehension. When you specify options like these and successfully obtain a certificate, those options are saved in the renewal configuration file under /etc/letsencrypt/renewal, and will be used automatically by certbot renew in the future. So autorenewal should still be possible in this setup.

The main case that can't autorenew is --manual (or --authenticator manual), but you didn't use that, so you shouldn't be affected by it!

You’ve been an incredible help, thanks so much!

@schwim Did you really need the standalone authenticator? Didn’t the webroot authenticator work for you?

Also, with recent versions of certbot, the apache authenticator supports the http challenge. Which version do you use?

Hi there @Osiris and thanks for taking the time to help!

I apologize but I’m not sure what you mean. I tried the initial command listed in OP, received the warning, did some searching to find that Deb 9’s certbot seemed to be too old, requiring a workaround, found the workaround thread on this forum and ended up with a working cert.

Is there something I should have done differently?

No problem.

That's probably very true. I assume you're using the Debian stretch packages? Because that version is indeed very old, 0.10.2. However, the stretch-backports repository has a rather up to date version of 0.25! That's also the recommended method of installing certbot. But I don't use Debian myself, so I have no idea if you can combine stretch-backports just for certbot with the rest of your packages just stretch.

But anyway, that doesn't really matter, because even with the 0.10 there should be 2 options. See below:

Very nice! A working certificate is obviously the end goal here. However, there's still one thing I don't understand. In the workaround thread @schoen has provided, it mentions two possible workarounds:

  • "# Webroot method" (which uses --authenticator webroot)
  • "# Temporary outage method" (which uses --authenticator standalone, the one you're using)

I'm not sure why you've opted for the "temporary outage method"? Because it requires Apache to be stopped, cert to be renewd and Apache to be started again. Between starting and stopping, you're site will be down for just a moment.

The webroot method doesn't have that limitation. I'm not saying you did anything wrong, nor am I saying you should change anything, but I'm trying to figure out the reason why you opted for an option with downtime instead of the option without downtime.

Oh, I understand what you mean. To be honest, the only reason I didn't go that route is that I didn't understand that it would be the preferred method. I like the fact that it wouldn't require apache to restart.

Would I simply run this command to change the way certbot handles these two domains or would running this command somehow cause a problem with what I've already done?

certbot --authenticator webroot --installer apache --webroot-path /home/schwim/www/public_html -d -d

Seems correct to me, assuming the webroot path is correct for that website and there aren't any strange rewrite rules preventing the Let's Encrypt validation server from retrieving the token file from http://(www.)

It shouldn't if you haven't issued 5 or more certificates the past 7 days. Otherwise, you might run into one of the rate limits.

Please choose whether HTTPS access is required or optional.
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

Your existing certificate has been successfully renewed, and the new certificate
has been installed.

The new certificate covers the following domains: and

Worked like a champ, thanks so much!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.