The converted Caddyfile doesn’t seem to be taken into account.
4. Error messages and/or full log output:
user@computer:~/caddy_v2.4.6$ ./caddy2 run
2022/01/16 23:20:40.182 INFO using adjacent Caddyfile
2022/01/16 23:20:40.183 WARN input is not formatted with 'caddy fmt' {"adapter": "caddyfile", "file": "Caddyfile", "line": 1}
2022/01/16 23:20:40.184 INFO admin admin endpoint started {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["127.0.0.1:2019", "localhost:2019", "[::1]:2019"]}
2022/01/16 23:20:40.184 INFO http enabling automatic HTTP->HTTPS redirects {"server_name": "srv0"}
2022/01/16 23:20:40.184 INFO tls.cache.maintenance started background certificate maintenance {"cache": "0xc000227f10"}
2022/01/16 23:20:40.186 INFO tls cleaning storage unit {"description": "FileStorage:/home/user/.local/share/caddy"}
2022/01/16 23:20:40.186 INFO tls.cache.maintenance stopped background certificate maintenance {"cache": "0xc000227f10"}
run: loading initial config: loading new config: http app module: start: tcp: listening on :80: listen tcp :80: bind: permission denied
5. What I already tried:
I tried to use the caddy adapt command and also took a look on the documentation to know how some directives changed and make the corresponding changes on the root/proxy/log directives and passed the tls one for now.
Caddy wants to bind to port 80 to solve the ACME HTTP challenge. To bind to port 80, you need need to run as a privileged user which has permissions to bind to low ports (ports 1024 and under).
Since you’re running on Ubuntu, I recommend using our systemd service to run Caddy, which will make sure you’re running as a user which has permissions to bind to low ports:
If you’re using reverse_proxy, then there’s no reason to use root because nothing will actually use it. Using root is more for when you’re serving static files with file_server or running PHP code with php_fastcgi etc.
Why are you trying to port 44444 instead of the default HTTPS port of 443?
I’m exposing my web server through port 44444 because it’s only accessible through a VPN provider that allows me this specific port for port forwarding.
I don’t need to listen on port 80 since the certificates were already signed by Let’s Encrypt by another meaning (using lego project), and are directly given to caddy.
Any idea how to bypass the Let’s Encrypt ACME challenge ?
If you use the tls directive to give Caddy a cert and key, then it won’t enable ACME for that domain. But it will still set up HTTP->HTTPS redirects so it will bind to the default http_port which is 80. You can turn this off by using the global option auto_https disable_redirects or changing the http_port global option to some other high port.
Btw, just for fun, I did check on the corresponding JSON config and it’s just a no-brainer ahah. I’m glad my case isn’t so tricky so I can still do in on a simple Caddyfile!