A version of Certbot was just released with support for HTTP-01 in the Apache and Nginx plugins. See Certbot 0.21.0 Release for more info.
2 Likes
Did you get this figured out? I have the same setup with UnRaid running LE in a container. I set to use HTTP as mentioned but now I am getting the same error as you. The only difference is I am using Google DNS not duckdns. Any help would be appreciated. Thanks.
Will the TLS-SNI-01 challenge be re-enabled for certbot eventually? If so, is there an ETA for when? Days? Weeks?
We run multiple servers behind firewalls that purposefully block port 80, so they are only accessible on port 443. The thinking is if weâll never use 80, then block it. This rules out using the HTTP-01 challenge.
That leaves using the DNS challenge as the only avenue and while it seems like it will work, documentation and scripts and, cron entries and etc. will all need to have a âcaveatâ for servers that may use the DNS method.
I also think it would be very beneficial that this thread provide a âheads upâ for updates to certbot prior to their release. I tried this morning and it installed 0.21.0 certbot and the dependencies, but failed for my situation where the HTTP-01 challenge does me no good.
Long story short - feedback on ETA on TLS re-enabling and prior notification for certbot updates would go a long way.
I love the mission of LetsEncrypt and wish it would have been around years ago. I also appreciate the work being undertaken for nipping the TLS security challenge vulnerability before it became a major issue. That said, trying to express my love and appreciation to PHBs that want a working solution ASAP without being able to provide concrete answers or timelines, leaves them asking âWhy not stick with GoDaddy?â. PHBs are naive and have fragile egos, but can also wield unlimited power. Hopefully you can appreciate my dilemma.
It will not be re-enabled for new issuance. Check out this post: TLS-SNI challenges disabled for most new issuance. In short, renewals will continue to work, but new issuances will not offer TLS-SNI-01.
Note that this does not increase your security, and harms usability for visitors to your sites, since they cannot get a redirect to port 443. Also, in this case, it's ruling out a challenge type that might otherwise work for you. I would recommend reconsidering the decision to block port 80, if the HTTP-01 challenge works better for you than the DNS challenge.
@bmw What's the recommended channel for receiving notifications about pending or actual Certbot releases?
Also, my guess is that in addition to Certbot updates, you'd also like updates about the Let's Encrypt services. We have two official communication channels:
- The API Announcements category, for pre-announcement of changes to the API.
- Our status page, for announcements of outages or urgent service changes (like the TLS-SNI outage).
Both channels allow you to subscribe to get email notifications when there are updates.
Certainly I do, and we're always doing our best to make your life as easy as we can, within the limits of our commitment to security. 
2 Likes
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.
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