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.
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.
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.
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).
@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.
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)
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.