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

[Canadian]

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: https://testcrm2.dmcontact.com

I ran this command: certbot -d testcrm2.dmcontact.com

It produced this output: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

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

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

My hosting provider, if applicable, is: N/A

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

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

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

When I need to point out is I created 2 test websites after we discovered an oddity on our production systems. The first one https://testcrm1.dmcontact.com shows the certificate as functional, which was created with the typical certbot -d testcrm1.dmcontact.com which works fine. And with the second one I created a manual certificate, putting the TXT file on the DNS server, approving it, etc, etc, etc. And that worked fine as well. But I revoked that certificate, including deleting the certificate from the server, in an attempt to run certbot -d testcrm2.dmcontact.com. And it didn’t like that giving me the error above. Have I missed something using Certbot?

[mnordhoff]

This may be a bug that was probably fixed inadvertently in Certbot 0.31.0:

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

H…

The issue would be that Let's Encrypt may be returning a cached authorization, from when you used DNS validation. After a recent change in Let's Encrypt's API, the cached authorization includes only the DNS-01 challenge object from before.

Certbot sees that you want to use HTTP validation, but the authorization doesn't include that as a possibility -- because it's already valid and you don't need to validate again -- but Certbot gets confused and fails.

Can you post the /var/log/letsencrypt/letsencrypt.log from when this happens?

Any chance you want to ignore this issue until you upgrade to a newer version of Debian?

Debian 9 doesn't have a newer version of Certbot packaged, though you can switch to certbot-auto.

[Canadian]

I tested with certbot-auto and that immediately fixed the issue. I would agree it seems to be some sort of caching issue. Our next upgrade of Debian isn’t for a while, so the certbot-auto solution works out fine really. Thanks for the assistance.