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:
(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
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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).