Is there a way to instruct the client to connect back to the server using port 443 instead of 80? I’m getting the error Could not connect to http://foo.domain.bar/.well-known/acme-challenge/… – I’m not wanting to open up port 80, but I do have port 443 open for connections.
Ironic isn’t it. Let’s encrypt the web. But let’s require unencrypted access to do it.
1 Like
tls-sni-01 challenges work on port 443, if that's an option for you (it works differently and I'm not sure if you can avoid downtime with it).
There are security concerns with using https for http-01 challenges. SimpleHTTP supported https and was disabled for this reason. The attack vector is described in this mail to the acme list.
Furthermore, enabling optional https support on http-01 would be no security improvement, as any MITM in a position to spoof Let's Encrypt challenge verification could simply ask for a http check.
It's inconvenient for sites that are https-only, but that can't really be helped due to previously mentioned security concerns. tls-sni-01 (and soon dns-01) is available for users with this configuration.
2 Likes
Ah, okay. Is there a published list of source addresses that I could instead configure my firewall to pass through on port 80?
Is there documentation on tls-sni-01? I’m finding it hard to find full documentation on even things like command line usage. I’ve seen in other threads examples that aid a more automated scripting approach that skips any interaction like agreeing to terms of service, but the --help on the topics don’t seem to include that. Not sure if things like that have since been removed…
But overall, this is a very exciting project! Thank you for this. 
Not sure about this, but I think Let’s Encrypt doesn’t want to publish the IP ranges they use for verification, since they might change (which could silently break renewal for a large number of users if they’d encourage LE-specific firewall rules). There might have even been plans to send one of the verification requests via tor to make it harder to spoof the challenge, IIRC.
I believe tls-sni-01 is used by the standalone and apache plugins (documented here). Standalone mode would require stopping your web server, after which the client spawns a temporary web server on port 443 to complete the challenge. I’m not sure if you can avoid the downtime with tls-sni-01.
The challenge types are documented on a protocol level in this IETF draft document. Not all that relevant though, unless you wan to write your own client.
There are some alternative clients as well.
1 Like
Standard port usage require content served through TCP 443 is SSL-encrypted HTTP content, while TCP 80 is for unencrypted HTTP.
While validating the domain, you are supposed not having SSL encryption, thus it shall use the 80 port to enforce standard behavior.
If you firewall is open to the public on 443, I do not understand what the trouble is about opening 80 too.
That's correct.
Yep, if you don't want to open up port 80, I'd recommend using tls-sni-01. You can do this with zero downtime if you have Apache installed, with --authenticator apache on the official client. You can also in theory use the Nginx plugin, but it's highly experimental and I think is not bundled in the official release.
FWIW, I think it's perfectly reasonable to open up port 80 on a webserver, if all you do on that port is 301 to HTTPS. Remember that if someone is MitM'ing your site visitors, they can fake listening on port 80 anyhow. So offering port 80 with a redirect is a help to visitors who type in foo.domain.bar in their browser and don't yet have HSTS cached for your site, with effectively no additional security risk.
why not automate this, publish ips to a letsencrypt.org/ip.txt file and update them and then folks can automate and script the whitelisting by grabbing the ip.txt updated list of ips ? cloudflare and incapsula do this for their ipv4 or ipv6 based ip listings 
An interesting idea! But our validation is supposed to establish that a given server is available on the public Internet at the time of issuance. Obviously we can't control whether the server subsequently becomes unavailable, but we don't really want to encourage servers to firewall off access to only the validation IPs.
Well just having the ip.txt available won’t affect much as only folks who know what they are doing will properly maintain and firewall whitelist letsencrypt ips listed in ip.txt. To other regular folks the existence of ip.txt list has no bearing on how Letsencrypt validation servers operate 
Very easy to do with firewalls like CSF Firewall http://centminmod.com/csf_firewall.html
And what happens if LE makes a change to the list, and the firewall is only set up to update once a month?
Then the 30 days of grace period would go by, with the renewal failing.
folks implementing this would just need to be smarter… auto renewal cron jobs can auto update the whitelisting just before auto renewal = automation and scripting at it’s finest
example with csf firewall to white list ip
csf -a ip comment
so for cloudflare ips just a matter of a routine like
curl https://www.cloudflare.com/ips-v4 > $CFIPLOG
curl https://www.cloudflare.com/ips-v6 > $CFIP6LOG
CFIPS=$(cat $CFIPLOG)
CFIP6S=$(cat $CFIP6LOG)
for ip in $CFIPS;
do
csf -a $ip cloudflare
done
for ip in $CFIP6S;
do
csf -a $ip cloudflare
done
example output from csf firewall whitelisting of cloudflare ips
Adding 103.21.244.0/22 to csf.allow and iptables ACCEPT...
csf: IPSET adding [103.21.244.0/22] to set [chain_ALLOW]
Adding 103.22.200.0/22 to csf.allow and iptables ACCEPT...
csf: IPSET adding [103.22.200.0/22] to set [chain_ALLOW]
Adding 103.31.4.0/22 to csf.allow and iptables ACCEPT...
csf: IPSET adding [103.31.4.0/22] to set [chain_ALLOW]
Adding 104.16.0.0/12 to csf.allow and iptables ACCEPT...
csf: IPSET adding [104.16.0.0/12] to set [chain_ALLOW]
Adding 108.162.192.0/18 to csf.allow and iptables ACCEPT...
csf: IPSET adding [108.162.192.0/18] to set [chain_ALLOW]
Adding 141.101.64.0/18 to csf.allow and iptables ACCEPT...
csf: IPSET adding [141.101.64.0/18] to set [chain_ALLOW]
Adding 162.158.0.0/15 to csf.allow and iptables ACCEPT...
csf: IPSET adding [162.158.0.0/15] to set [chain_ALLOW]
Adding 172.64.0.0/13 to csf.allow and iptables ACCEPT...
csf: IPSET adding [172.64.0.0/13] to set [chain_ALLOW]
Adding 173.245.48.0/20 to csf.allow and iptables ACCEPT...
csf: IPSET adding [173.245.48.0/20] to set [chain_ALLOW]
Adding 188.114.96.0/20 to csf.allow and iptables ACCEPT...
csf: IPSET adding [188.114.96.0/20] to set [chain_ALLOW]
Adding 190.93.240.0/20 to csf.allow and iptables ACCEPT...
csf: IPSET adding [190.93.240.0/20] to set [chain_ALLOW]
Adding 197.234.240.0/22 to csf.allow and iptables ACCEPT...
csf: IPSET adding [197.234.240.0/22] to set [chain_ALLOW]
Adding 198.41.128.0/17 to csf.allow and iptables ACCEPT...
csf: IPSET adding [198.41.128.0/17] to set [chain_ALLOW]
Adding 199.27.128.0/21 to csf.allow and iptables ACCEPT...
csf: IPSET adding [199.27.128.0/21] to set [chain_ALLOW]
checking cloudflare ips in whitelist i.e. 103.21.244.0/22
csf -g 103.21.244.0/22
Chain num pkts bytes target prot opt in out source destination
No matches found for 103.21.244.0/22 in iptables
IPSET: Set:chain_ALLOW Match:103.21.244.0/22 Setting: File:/etc/csf/csf.allow
csf.allow: 103.21.244.0/22 # cloudflare - Thu Dec 10 08:28:28 2015
csf.allow file
grep cloudflare /etc/csf/csf.allow
103.21.244.0/22 # cloudflare - Thu Dec 10 08:28:28 2015
103.22.200.0/22 # cloudflare - Thu Dec 10 08:28:29 2015
103.31.4.0/22 # cloudflare - Thu Dec 10 08:28:29 2015
104.16.0.0/12 # cloudflare - Thu Dec 10 08:28:29 2015
108.162.192.0/18 # cloudflare - Thu Dec 10 08:28:29 2015
141.101.64.0/18 # cloudflare - Thu Dec 10 08:28:30 2015
162.158.0.0/15 # cloudflare - Thu Dec 10 08:28:30 2015
172.64.0.0/13 # cloudflare - Thu Dec 10 08:28:30 2015
173.245.48.0/20 # cloudflare - Thu Dec 10 08:28:30 2015
188.114.96.0/20 # cloudflare - Thu Dec 10 08:28:31 2015
190.93.240.0/20 # cloudflare - Thu Dec 10 08:28:31 2015
197.234.240.0/22 # cloudflare - Thu Dec 10 08:28:31 2015
198.41.128.0/17 # cloudflare - Thu Dec 10 08:28:31 2015
199.27.128.0/21 # cloudflare - Thu Dec 10 08:28:32 2015
run this just before the letsencrypt auto renewal cronjob command itself
IP addresses in text files? Ever heard of DNS?
As for the problem: If you have no problem running httpd with a hugely complex TLS library attached, where is the problem in running the same httpd without the complexity?
You are viewing this from the wrong angle. Actually, HTTPS is the more dangerous thing to run with respect to the safety of your server, because of said complexity of the TLS code. If you don’t host any content via HTTP, there is no problem to open port 80 if you have port 443 open anyway.