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

Awesome feedback and I appreciate the super quick response.

Just for clarity for myself and all following this thread - Is the TLS-SNI challenge essentially dead, from here on forward, for all new issuances? I’m pretty sure I read in a different thread it was re-enabled for some of the “Big Boys”. I was under the impression that TLS-SNI challenges were only temporarily disabled.

Futhermore, if HTTP-01 and DNS challenges are the sole remaining options, if a new issuance is done via HTTP-01, will renews require HTTP-01 or will they default to the TLS-SNI challenge? If allowing port 80 was under my control, it would be. My PHBs also have excessively tight sphincters when it comes to security, which I get from a certain point of view.

I’m just trying to determine whether using the DNS challenge is the best fit long term for my situation.

Again, thanks to the team for all it does.

Yep.

This is true, though we are working with those large hosting providers to move them to HTTP-01, or to some possible future validation method that uses TLS but is more secure. Discussions about possible future methods are happening on the IETF ACME mailing list.

This was our original plan, but it changed as we learned more about the extent of the problem.

Renewals can happen under TLS-SNI, even if the original issuance was via HTTP-01. However, I'd definitely recommend against this as a strategy for long-term maintenance. :slight_smile:

If you have the ability to automatically integrate the DNS challenge, it is generally a great choice. It works for situations where you have multiple servers serving the same hostname. It will also be required if you want to issue wildcard certificates once our v2 API launches.

2 Likes

WOW!!! Outstanding support!

Head down to your local bar/pub/watering hole and tell them the first round is on me.

Drink fast and then run like hell.

IMO: Let’s Encrypt has been a great effort up until this point. A fantastic effort and service for test and dev environments.

However, I have informed customers to consider full service certificate providers again because of disruptions like this. Even before, users that make use of a CDN, such as CloudFlare, have to be offline to renew and recycle the web service. For those running high volume ecommerce sites, even a minute of downtime would pay for a cert from Comodo for several years.

As such, any AWS aMi STACX customer that is looking to remedy this issue need to perform the following:

~$ wget https://dl.eff.org/certbot-auto
~$ chmod a+x ./certbot-auto

sudo ./certbot-auto --apache -d example.com

Select Option [2] for http to https redirection

Contact support for any further assistance!

We will look to remedy this in future stack releases.

Thanks!

A.I

The HTTP-01 and DNS-01 methods (which are the only ones that are still available to the public) should work properly with a CDN like CloudFlare.

3 Likes

I tried a few options but it continues to throw errors. I am probably too much of a noob to figure this out.

In the meantime, I decided to try a different solution for remote access using openvpn and it works without any issues.

I actually figured it out. So in UnRaid my docker container for LE was
forwarding port 80 to port 81. In my router i forwarded port 80

81local and the HTTP validation then worked. I have open VPN as well
but let's encrypt with Organizr is way too sweet to not have working.
Thanks for the response.

OK thanks for the notice! Since Debian Stretch (backports) still has an old version, 0.19 if I’m not wrong, I used the certbot-auto which works great. Thanks!

Even so, I created a symbolic link from /usr/bin/certbot to my certbot-auto location, so the certbot command is using the latest version (currently 0.21).

Is this a good practice? I think so…

The symlink may get overwritten when your OS-provided python-certbot packages get updated.

It may be better to just commit to one version and fully remove the other.

1 Like

I do get that, but at the same time I like to have the python-certbot-nginx package from the Debian Stretch backports…

@bmw What’s the recommended channel for receiving notifications about pending or actual Certbot releases?

Sorry for my delayed response here.

Probably the best way to get announcements for Certbot releases is to subscribe to the certbot-dev mailing list. In theory, this list is also used for general Certbot development discussion but in practice it's mainly used for announcing releases as they happen. We also always make a post in the client-dev category of this forum, but that has a lot more additional traffic than Certbot announcements.

Tracking Certbot changes before they happen is a bit difficult as what changes in a release is usually pretty dynamic due to pull requests from outside contributors, bug reports, and changes in Certbot's dependencies, but the best way to try and do something like that is to watch Certbot's milestones. We make a milestone for each release and put the issues we're planning on closing in that release into the milestone.

Is there a reason why HTTP-01 can not be extended to use https/port 443 connection instead, where it just ignores the server certificate all together? This way for renewals it will ignore the expired certificate and for new certificates I could just use a temporary self-signed certificate for startup. This would take care of the issue where port 80 is blocked. I do not see how this would be any less secure than using a straight http connection.

This has been requested a lot but it is not secure, especially in shared hosting environments.

2 Likes

Hello,

Forgive me, if the answer has been already be answered but I am a newbie and I am not sure if I understood well. If I want to create a new certificate for a new domain (my VM is an Ubuntu server 16.04 Apache)

I should run the command the below command ?

sudo certbot --authenticator webroot --installer apache\ --webroot-path /var/www/html/mynewsite -d mydomain.com -d www.mydomain.com

Thanks a lot for your help!

It may be worth updating this example to clarify that the backslash isn't actually part of the command... I get why it's there but it seems to be confusing some folks.

2 posts were split to a new topic: Timeout during validation

Awesome! thank you, you saved my day :slight_smile:

A post was split to a new topic: Certbot and related packages held back on Ubuntu

A post was split to a new topic: Wildcard request: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA