--http-01-port/--dvsni-port ignored by auth check from --server

[IzzySoft]

As I don't want to shutdown my web server (running multiple VHosts) for cert creation/renewal, I've tried using the --http-01-port and --dvsni-port parameters, using 8081 and 8082 as ports. While the client starts up the servers correctly (according to the logs: DEBUG:letsencrypt.plugins.standalone:Stopping server at 0.0.0.0:8081), verification seems to ignore this:

Failed authorization procedure. www.domain.tld (http-01): unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.domain.tld/.well-known/acme-challenge/los4uL881Tl5T2-Nk9drYgJnzA5wIU_4yjMaRuRppXI [111.222.333.444]: 404

Note the missing port in the URL – which made the running Apache answer the request; the Apache logs confirm this:

"GET /.well-known/acme-challenge/los4uL881Tl5T2-Nk9drYgJnzA5wIU_4yjMaRuRppXI HTTP/1.1" 404 1058 107074 "-" "boulder (LetsEncrypt.org)"

So somehow the detail which port to use gets lost on the way to the remote server (boulder).

System: Debian Wheezy with the client just installed a few hours ago via git clone. Example command used:

./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory --http-01-port 8081 --dvsni-port 8082 auth --standalone-supported-challenges http-01

(note that I've added --standalone-supported-challenges http-01 only in a last run for verification. Tried the same specifying dvsni, same results: though I specified --http-01-port 8081 --dvsni-port 8082, the incoming requests happen on ports 80 resp. 443.)

I don't want a downtime of several minutes just for refreshing certs – and I don't want to risk Apache not starting up if something goes wrong. So what's the correct way to have the challenge using different ports then? Related issue: #1164

[pde]

You can't make the server switch ports at the moment, and it will never support arbitrary ports (though maybe one day it will support a single unusual privileged port). We should document this, however.

[bmw]

I'm sorry for any confusion the existence of these flags caused. The --http-01-port and --dvsni-port parameters are found under letsencrypt-auto --help testing. The description of that section is:

  The following flags are meant for testing purposes only! Do NOT change
  them, unless you really know what you're doing!

Setting --http-01-port or --dvsni-port will not work in production and the setting of these flags has no effect on the behavior of boulder.

As you do not want to shutdown your server or use the Apache plugin, I recommend you take a look at webroot. The basic idea here is to use your existing webserver to serve the files that need to be provisioned for domain validation. No shutdown of Apache necessary.

[IzzySoft]

Thanks for the explanation! Indeed it's a bit confusing why the client is able to switch ports while the server doesn't support it (so I've suspected the documentation being "behind", as it doesn't seem to make sense).

Also thanks for the pointer with webroot, which indeed seems to be the answer to my issue; I will try that instead then. Though if I understand correctly, that requires to setup some public_html with the web server (if I remember correctly, that was something like the ~user/ dirs), which is not always wanted; so this is rather a work-around than a real solution. "Port flexibility" would be prefered here.

PS: For some practical examples on using "webroot", it might be worth seeing the discussion on its initial article in Using the webroot domain verification method. While the article itself might be slightly outdated (some steps no longer apply with that patch being merged), the comments below it give several good examples for Apache and Nginx.

[matwey]

You probably want to make reverse proxy at frontend HTTP server for /.well-known/acme-challenge/ to the port you need.

[IzzySoft]

@matwey No, I don't – as there is no "frontend HTTP server" before the one updated :) As described above, it's working for me currently, so I don't want to change it.

[dperetti]

Still confusing in 2018 !

[IzzySoft]

I've meanwhile completely switched to acme.sh and hence no longer can test any upcoming solutions/work-arounds/whatever, so I'm unsubscribing from this issue. Thanks for all hints – webroot did it for me back then (and in principle, that's what acme.sh uses as well).