Help converting a v1 Caddyfile

1. Caddy version (caddy version):

v2.4.6

2. How I run Caddy:

It’s run from /etc/rc.local, but can be started manually to test things.

a. System environment:

Ubuntu 20.04 LTS server LXC

b. Command:

/home/usrer/caddy_v2.4.6/caddy2 run

c. My complete Caddyfile working on v1

:44444, mywebsite.com:44444 {
        root /home/user/webroot_tmp/
        log caddy_access.log

        proxy / 127.0.0.1:8080

        tls mywebsite.ca.crt mywebsite.ca.key {
                clients /home/user/certificats_caddy/ca.crt
        }
}

d. My v2 Caddyfile attempt

:44444, mywebsite.com:44444 {
        root * /home/user/webroot_tmp/
        log

        reverse_proxy 127.0.0.1:8080
}

3. The problem I’m having:

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 would like to proceed as I was doing before.

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 ?

Kind regards

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.

Thanks for your answer!

I indeed forgot to add the TLS directives in the v2 Caddyfile -_-"…

The “root” line was a leftover that didn’t do harm since the proxy/reverse_proxy lines were doing their jobs.

But I indeed needed the last 2 options you gave me.

So here it is, a working Caddy v2 Caddyfile, that work as it did on Caddy v1:

{
	https_port 44444
	auto_https disable_redirects
}

:44444, mywebsite.com:44444 {
	log
	tls mywebsite.com.crt mywebsite.com.key {
		client_auth {
			mode require_and_verify
			trusted_ca_cert_file /home/user/certificates/ca-cert.pem
		}
	}
	reverse_proxy 127.0.0.1:8080
}

Thanks a lot for your help!

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!

Kind regards

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.