I am running a few servers that are secured with Letsencrypt and was struggling with how to get auto-renew working. I finally figured out what seems to trip it up: All my servers run https only and it appears that the auto-renew fails unless it can connect on port 80.
Is this observation correct? And if so, how do I work around it? I don’t like leaving port 80 open at all on any of these servers.
For HTTP-01 validation, that’s correct.
You may use:
If you are not sure if your server supports ALPN, check it out here: https://tools.keycdn.com/http2-test
Hmm, that’s odd: The test tool comes back saying my server does support APLN. Should certbot pick this up automatically or do I need to run it with some switch?
Supporting ALPN doesn’t really matter. Every webserver that supports HTTP/2 supports ALPN. If your webserver doesn’t understand how to route different ALPN protocols to different destinations, then it doesn’t help.
For example, like in this example: https://github.com/lukas2511/dehydrated/blob/master/docs/tls-alpn.md
Ok, I think I understand how it is supposed to work. But then of course the next question is, how do I make this work with Certbot? Or more generically, how do I make auto-renewal of the certificates work with a site that has only https turned on?
The easy option is to turn on HTTP, unless you really can’t.
Certbot doesn’t currently implement TLS-ALPN validation.
It does support DNS validation, but it only supports automated validation with certain DNS services, and which ones are easy to install depends on your OS.
Hi @klausson
I think this isn’t a good choice. It’s a bad choice.
A lot of users type domainname.com or www.domainname.com, browsers and search engines first try http.
And http should correct redirect to https. So no content is available via http.
So removing http doesn’t help to secure the server, but produces trouble to users.
@JuergenAuer if you put the domains on the HSTS preload list, this shouldn’t be a problem - at least not for endusers with halfway modern browsers 
No idea whether search engines care about the preload list, though…
I know, my main domain has position ~~12.000 in the Google Preload list (complete ~ 60.000). But there are millions of domains not preloaded.
And if port 80 has only redirects, I don’t see a security problem.
I completely agree with @JuergenAuer on HTTP access.
Considering that the HTTP and HTTPS don’t need to be handled by the same service, nor even by the same system.
You only need access to the folder where the http://{domain}/.well-known/acme-challenges/ will be found.
You can combine Apache with NGINX (one for http, one for https) in the same system.
You can combine two different systems (that share a folder - through NFS or rSYNC)
There’s almost none, except that in case the very first request contains something sensitive in the URL. Depending on your project, that might already be too much. Though I’d say that’s not the case for most websites.
If the URL contains the sensitive information, it is too late to secure it - the request went out over the Internet.
Dropping the request at the server does nothing…
If the reply is the one with the sensitive information, you have configured your system incorrectly - it should require TLS to interact with any sensitive areas.
If you are super paranoid (like me - lol), you would completely separate http from https traffic.
The https traffic is the one that does all the “work”.
The http traffic is merely there to nudge those older systems and point them in the right direction and to validate cert challenge requests.
You merely need to pass those certs to whichever systems will actually be using them (internally).
If there’s nothing listening on port 80, the connection won’t open and the request will not be sent over the internet.
Not listening won’t stop a request to contain sensitive information.
Stop this at your server:
http://your.server/?user='myusername'&passowrd='my.super.secret.password'
Too late - it went from my browser to the Internet and now the entire world has seen it.
Responding and processing http connections as if they are secure can lead to insecure “conversations” - that may contain sensitive information.
The last time I checked, a TCP connection doesn’t send data until the first handshake completed. If the remote server is not ACKing, the connection won’t open, and no content will be sent.
Except of course if your browser sends that URL to other servers as well (like search engines).
So you mean to say that there are http links already out there that contain sensitive information and you are securing them by ignoring them altogether?
That will make that problem go away.
If you separate http from https - like by using two completely separate servers (responding to same Internet IP), then how can the http server know anything about the https server unless you tell it.
The http will not know anything (out-of-the-box) and all you need to teach it is to process /.well-known/acme-challenges/ and to redirect all other http connections to https.
Then you teach the https server(s) to get their certs from the (shared) http server folder - or a common shared location in your internal network.
If a service accepts such a query, this is a security hole.
But then it’s irrelevant if port 80 is open or closed.
Most “coffee shop”-style attacks will just perform an active MITM and be happily complete any TCP handshakes, regardless of what the real remote host says.
But you’re right, for the case where the adversary is passive-only, this might protect your users.
I would agree that HSTS (+ preload if you are using something like capability URLs in emails or something), as suggested, does a better job without making life complicated.