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

My operating system is (include version):

Ubuntu 16.04

I installed Certbot with (certbot-auto, OS package manager, pip, etc):

OS Package Manager

I ran this command and it produced this output:

sudo certbot renew --dry-run
or
sudo certbot --nginx -d [hostname]

Certbot's behavior differed from what I expected because:

¯_(ツ)_/¯

Here is a Certbot log showing the issue (if available):

Logs are stored in `/var/log/letsencrypt` by default. Feel free to redact domains, e-mail and IP addresses as you see fit.

2018-01-10 04:20:37,807:INFO:certbot.auth_handler:Performing the following challenges:
2018-01-10 04:20:37,808:CRITICAL:certbot.auth_handler:Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
2018-01-10 04:20:37,810:WARNING:certbot.renewal:Attempting to renew cert (www.coolsite.com) from /etc/letsencrypt/renewal/www.coolsite.com.conf produced an unexpected error: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.. Skipping.
2018-01-10 04:20:37,812:DEBUG:certbot.renewal:Traceback was:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 425, in handle_renewal_request
main.renew_cert(lineage_config, plugins, renewal_candidate)
File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 743, in renew_cert
_get_and_save_cert(le_client, config, lineage=lineage)
File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 80, in _get_and_save_cert
renewal.renew_cert(config, domains, le_client, lineage)
File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 297, in renew_cert
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 318, in obtain_certificate
self.config.allow_subset_of_names)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 68, in get_authorizations
self._choose_challenges(domains)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 103, in _choose_challenges
self.authzr[dom].body.combinations)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 374, in gen_challenge_path
return _find_smart_path(challbs, preferences, combinations)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 411, in _find_smart_path
_report_no_chall_path()
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 442, in _report_no_chall_path
raise errors.AuthorizationError(msg)
AuthorizationError: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

Here is the relevant nginx server block or Apache virtualhost for the domain I am configuring:

server {
listen 3002;
server_name www.coolsite.com;

location / {
    proxy_pass http://coolip:3002;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
 }

}

Unfortunately, Let's Encrypt has stopped offering the mechanism that Certbot's Apache and Nginx plugins use to prove you control a domain due to a security issue. See https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 for more info.

We are planning on releasing a new version of Certbot in the next few days that works around this but if you have to obtain/renew your cert and cannot wait, you have a couple of options. If you're serving files for that domain out of a directory on that server, you can run the following command:

sudo certbot --authenticator webroot --installer nginx

If you're not serving files out of a directory on the server, you can temporarily stop your server while you obtain the certificate and restart it after Certbot has obtained the certificate. This would look like:

sudo certbot --authenticator standalone --installer nginx --pre-hook "service nginx stop" --post-hook "service nginx start"

These hooks will cause Certbot to automatically stop your server to obtain certificates and then start it again. After running a command like this once, Certbot will remember your settings so certbot renew will work in the future.

For other people who find this issue, this affects some of our other plugins as well such as the Apache plugin. All the advice above is identical except you should replace nginx with apache in the different CLI options.

EDIT: The post hook in the 2nd example was previously "server nginx stop" but I changed it to the correct value of "service nginx start".
EDIT2: Updated the beginning of the post in response to TLS-SNI-01 being permanently disabled.

When I do the 2nd option, I get an error saying it is unable to connect to domain. It's trying to connect via port 80, but the site is hosted on a custom port. Where do I tell it to do the authentication via a custom port?

Thanks for the insanely quick response, I wasn't finding anything online.

When I do the 2nd option, I get an error saying it is unable to connect to domain. It's trying to connect via port 80, but the site is hosted on a custom port. Where do I tell it to do the authentication via a custom port?

If you need Certbot to listen on a different port, you can include --http-01-port <port> on the command line, but if I'm understanding you correctly, the problem is that Let's Encrypt server externally is attempting to connect via port 80. Unfortunately, you cannot change this and Let's Encrypt will always attempt to connect to your server via this port.

If you need a cert now and can't (even temporarily) use one of the above options, you can also look at our manual plugin. I left instructions about how to use this out of my previous response as it can be a little tedious, but it allows you to work around more complex setups. Set --authenticator manual on the command line and it will walk you through manually setting up the challenge or alternatively, you can provide scripts for the manual plugin to run to set up and tear down the challenge as described in the link.

Thanks for the insanely quick response, I wasn't finding anything online.

Thanks for the kind words! Happy to help.

The sites are listening on custom ports locally (3000 range), but only expose the ssl port (5000 range) to the public.

I can temporarily change the port, but there are three hosts on here and that's just a big pain to keep doing. I guess I can add it into a script to modify the host file to expose port 80 then switch it back after.

I'll look to see if the manual way is more or less work.

What's the likelihood this will be resolved and auto-renew will work again with nginx?

Just did it manually, it's not too bad, but obviously can't auto-renew, but the DNS option is quick and painless.

Thanks!

Great! In the future when this incident is resolved if you want to switch back to the old authentication method so certbot renew works, just run:

sudo certbot --nginx -d <domain> --force-renewal

This will cause Certbot to renew your certificate even it's not close to expiration, but it will remember the settings it used to obtain the cert and use them with certbot renew going forward.

Best way to be notified when the issue is resolved?

You can just watch this issue. This is going to be a common problem for people until it is resolved so we can leave it open until then.

I apologize for being "that guy" but is there an estimate that anyone knows of for a resolution to this?

Hi,

I tried the second option but hit this error:

Starting nginx: [FAILED]

Hook command "service nginx start" returned error code 1
Error output from service:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()

Problem binding to port 80: Could not bind to IPv4 or IPv6.

Cannot see a new certificate on the server so assuming it didn't work at all.

Do you have any advice on how to get round this please?

Thanks BMW. I had the same issue with apache. For those working with apache, this worked for me:

certbot --authenticator standalone --installer apache -d <yourdomain> --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2"

for debian/ubuntu:
certbot --authenticator standalone --installer apache -d <yourdomain(s)> --pre-hook "apache2ctl stop" --post-hook "apache2ctl start"

For those watching: it hasn't been explicitly said in here, but this appears to be the source: TLS-SNI-01 has been deactivated as authentication scheme because of security issues.
https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996
https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188

iabel's method worked for me on Debian 9 (which uses systemd by default).

Hi everybody,
I didn't understand yet how renew existing certificates obtained with TLS-SNI-01 challenge. Do I have to obtain new certificates with the suggested "webroot" method (that indeed works perfectly for new domains) manually for every domain? What if I have many of them?

Thx to all

@chris001

@chris001

You can workaround by modifying your site to get the cert, either run certbot in standalone mode, or in webroot mode, or download and use cerbot-auto which contains the fix.

I believe I tried all these methods and I still get the error about DNS issues. Is there any detailed, manual installation guide for certbot 0.21? Like downloading the source from a repository to the server, then using that to install certbot. I am running nginx on Ubuntu Trusty 14.04 and they haven't updated their PPA for certbot.

The certbot-auto method didn't work for me either. All these methods eventually lead to either some errors in installation or fail to recognise the domain name. Even though the domain works.

I may just have to give up on letsencrypt and just get a domain with included ssl and call it a day. This whole chain of weak links between Ubuntu maintainers - letsencrypt and whatnot is making me waste time I could use to be more productive.

Sadly the web world is full of such weak links. We need another model for the web.

Sounds like sombody isn’t happy with there free software, better get him a refund!

In all seriousness though, this is the risk you take when it doesn’t cost a penny, paid certs means that sombody has an incentive to make things as easy as possible for you, so it’s definitely a good option.

My main reason for let’s encrypt is the 3 month auto renewal system. It’s just a better way of handling certs

@ciprianflorescu

@ciprianflorescu I would like to point out that you could seek paid support from one of many providers. Regardless, I went ahead and spun up a server running Ubuntu 14.04 to demonstrate how to run certbot-auto and made a video for you on YouTube. Watch the video if you want. It shows the process working flawlessly.

@ciprianflorescu

@ciprianflorescu @falconmick @FlippingBinary @fkrauthan
The Ubuntu PPA for certbot is updated now to 0.21.1 - thanks to certbot ppa maintainers. sudo apt-get upgrade and then cerbot command should work fine for you now.

@jmpinto
If you use certbot-auto on centos 6, it should download the newest version certbot 0.21+ and work fine and it will even install your LE TLS cert into apache2, as long as your specify apache2 on the command line. Watch video of @FlippingBinary https://youtu.be/0TYjZ_TYr-s to learn how to run the process of certbot-auto.

Thanks to everyone who put in the hard work!

@chris001

@chris001 ugrade => upgrade

@falconmick

Thanks for your answers, I already bought a cert from a provider.

@falconmick So this time if something doesn't work, I can actually get that refund you were so concerned about. That's what I call accountability.

Thank you to the whole Certbot team!! We're starting a monthly donation to EFF in your honor (https://supporters.eff.org/donate) - If there's a way to earmark it for your team, please let us know.

Just to mention that the command that was previously shown for a system by "BMW" actually works as-is for Raspbian OS on my Raspberry pi:

certbot --authenticator standalone --installer apache -d <yourdomain> --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2"

I only substituted "-d " with the multiple ones I have for my cert. And since I have several domain names, I put the whole thing in a script. Works perfectly for me.

Big update.

On that note, I think this resolved issue has outlived its usefulness. As always, if anyone has an honest issue using Certbot or has a bug report or feature request, please feel free to make a new issue or topic on https://community.letsencrypt.org respectfully explaining it and people will be happy to help you.

Navigation Menu

Repository navigation

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

My operating system is (include version):

I installed Certbot with (certbot-auto, OS package manager, pip, etc):

I ran this command and it produced this output:

Certbot's behavior differed from what I expected because:

Here is a Certbot log showing the issue (if available):

Logs are stored in `/var/log/letsencrypt` by default. Feel free to redact domains, e-mail and IP addresses as you see fit.

Here is the relevant nginx server block or Apache virtualhost for the domain I am configuring:

59 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

My operating system is (include version):

I installed Certbot with (certbot-auto, OS package manager, pip, etc):

I ran this command and it produced this output:

Certbot's behavior differed from what I expected because:

Here is a Certbot log showing the issue (if available):

Logs are stored in /var/log/letsencrypt by default. Feel free to redact domains, e-mail and IP addresses as you see fit.

Here is the relevant nginx server block or Apache virtualhost for the domain I am configuring:

Activity

bmw commented on Jan 10, 2018

officiallymarky commented on Jan 10, 2018

bmw commented on Jan 10, 2018

officiallymarky commented on Jan 10, 2018

officiallymarky commented on Jan 10, 2018

bmw commented on Jan 10, 2018

officiallymarky commented on Jan 10, 2018

bmw commented on Jan 10, 2018

christopherfowers commented on Jan 10, 2018

hola56 commented on Jan 10, 2018

iabel commented on Jan 10, 2018

taur commented on Jan 11, 2018

ccoenen commented on Jan 12, 2018

artfulrobot commented on Jan 12, 2018

Lonni93 commented on Jan 12, 2018

59 remaining items

ciprianflorescu commented on Feb 5, 2018

falconmick commented on Feb 5, 2018

FlippingBinary commented on Feb 5, 2018

chris001 commented on Feb 5, 2018

falconmick commented on Feb 5, 2018

cyio commented on Feb 6, 2018

ciprianflorescu commented on Feb 8, 2018

HaeckDesign commented on Feb 9, 2018

jfmessierdotca commented on Feb 13, 2018

bmw commented on Mar 21, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Logs are stored in `/var/log/letsencrypt` by default. Feel free to redact domains, e-mail and IP addresses as you see fit.