From my investigations HTTP-01 challenge will not work on other ports - https://letsencrypt.org/docs/challenge-types/#http-01-challenge. But in a normal/my setup you have a router that is doing port forwarding (from 80 -> 10080 and 443->10443 in my case) and I assume will work. I tested with DNS-01 challenge since is also more robust for root and wildcard as well - https://letsencrypt.org/docs/challenge-types/#dns-01-challenge (see #2222 )

@githubsaturn Please let me know if I need to fix something more.

Just to confirm, this won't work out of the box with Let'sEncrypt etc, right? This assumes that there is a port forwarder somewhere in front of the server that forwards 80/443 to the custom ports on the server?

Will not work out of the box because the default Let'sEncrypt is using http-01-challenge that is expecting port 80/443.

Solutions:

• Have a front forwarder that listens on 80 and 443
• Have dns-01-challenge configured that is not depending on ports accessibility at all. One more advantage to be used in the future as default is that supports wildcard certificates easily.

Anyway without a forwarder the client/dashboard app must be changed to show and use the ports so maybe is not a good ideea.

The main scenario that I'm expecting to be needed and I saw in all the issues is just the capability to run on any ports since they are occupied and have a forwarder with virtual hosting in front or just a router.

This is a potentially exciting feature.

I just had one quick last-minute thought, couldn't the port forwarding be done entirely within the same system?

For example, to forward port 80 to port 8080, one could add the following to the top of /etc/ufw/before.rules:

*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
COMMIT

Am I missing something, or could that be an approach to implementing this with http verification without requiring a separate router doing its own NAT?

I'm thinking that, if it could be done this way, then it could be scripted and made available as an optional setup routine that wouldn't require the user to manually configure anything, internally or otherwise.

EDIT: Made the code reflect the example from https://serverfault.com/questions/238563/can-i-use-ufw-to-setup-a-port-forward.

Am I missing something, or could that be an approach to implementing this with http verification without requiring a separate router doing its own NAT?

Having spent the last several minutes searching for someone documenting this exact process in the context of LE certificate requests, I must be missing something, if it were this easy it'd be an accepted solution all over the place, as this isn't an especially rare scenario. This is closest thing I've found, and while it doesn't necessarily support this approach for this explicit context, none of the replies seem to rule it out either: https://serverfault.com/questions/238563/can-i-use-ufw-to-setup-a-port-forward

I wanted to add the capability to run on a different port like 10080/10443/13000(in my case was synology) because port 80/443 was already reserved by the system. In my case using port 80 was not possible at all.
I'm not sure exactly if this would work as I'm testing this in windows with wsl.

This is closest thing I've found

I managed to run a simple nginx proxy from 80 and 443 to 10083 and 10443 with this oneliner (switched to 10083 since 10080 is filtered by chrome/firefox as problematic):

docker run --rm -p 80:80 -p 443:443 --name forwarder nginx:alpine sh -c "echo '
events {}
stream {
    server {
        listen 80;
        proxy_pass 172.17.0.1:10083;
    }
    server {
        listen 443;
        proxy_pass 172.17.0.1:10443;
    }
}
' > /etc/nginx/nginx.conf && nginx -g 'daemon off;'"

After this curl on http://localhost:80, http://localhost:10083, https://localhost:443 and https://localhost:10443 all should work.

Thanks!

Hi there! Still can't run on docker with different ports, i added -e CAPTAIN_HOST_HTTP_PORT=8080 and so on at the docker run execution still my caprover container keeps crashing after logging that i have to wait 60 seconds