Skip to content
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
Closed

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

IzzySoft opened this issue Nov 5, 2015 · 7 comments

Comments

@IzzySoft
Copy link

@IzzySoft 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
Copy link
Member

@pde 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 added this to the Nice for 1.0 milestone Nov 5, 2015
@pde pde removed this from the Nice for 1.0 milestone Nov 5, 2015
@bmw
Copy link
Member

@bmw 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 as completed Nov 5, 2015
@IzzySoft
Copy link
Author

@IzzySoft 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
Copy link

@matwey 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
Copy link
Author

@IzzySoft 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
Copy link

@dperetti dperetti commented Jun 26, 2018

Still confusing in 2018 !

@IzzySoft
Copy link
Author

@IzzySoft 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
Projects
None yet
Development

No branches or pull requests

5 participants