New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
IzzySoft opened this Issue Nov 5, 2015 · 7 comments

Comments

Projects
None yet
5 participants
@IzzySoft
Copy link

IzzySoft commented Nov 5, 2015

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

This comment has been minimized.

Copy link
Member

pde commented Nov 5, 2015

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.

@pde pde modified the milestone: Nice for 1.0 Nov 5, 2015

@bmw

This comment has been minimized.

Copy link
Contributor

bmw commented Nov 5, 2015

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.

@bmw bmw closed this Nov 5, 2015

@IzzySoft

This comment has been minimized.

Copy link

IzzySoft commented Nov 5, 2015

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

This comment has been minimized.

Copy link

matwey commented Jul 4, 2016

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

@IzzySoft

This comment has been minimized.

Copy link

IzzySoft commented Jul 4, 2016

@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

This comment has been minimized.

Copy link

dperetti commented Jun 26, 2018

Still confusing in 2018 !

@IzzySoft

This comment has been minimized.

Copy link

IzzySoft commented Jun 26, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment