Caddy won't start - Could not start HTTP server for challenge -> listen tcp :80: bind: permission denied

Help
1

Hi,

I’m trying to get Caddy running on a fresh Ubuntu 16.04 server and trying to stay as close to stock config as possible.

root@sheaf:~# caddy --version
Caddy 0.10.6

root@sheaf:~# ls -la /usr/local/bin/caddy
-rwxr-xr-x 1 root root 17007656 Jul 28 18:28 /usr/local/bin/caddy

root@sheaf:~# which caddy
/usr/local/bin/caddy

I have installed the systemd service as per https://github.com/mholt/caddy/tree/master/dist/init/linux-systemd (verbatim) and followed the steps. When I start caddy I get this:

root@sheaf:~# systemctl start caddy
root@sheaf:~# systemctl status caddy
● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-08-18 11:11:04 UTC; 453ms ago
	 Docs: https://caddyserver.com/docs
  Process: 2148 ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp (code=exited, status=1/FAILURE)
 Main PID: 2148 (code=exited, status=1/FAILURE)
	  CPU: 607ms

Aug 18 11:11:01 sheaf systemd[1]: Started Caddy HTTP/2 web server.
Aug 18 11:11:02 sheaf caddy[2148]: Activating privacy features...2017/08/18 11:11:02 [INFO][mydomain.example.com] acme: Obtaining bundled SAN certificate
Aug 18 11:11:03 sheaf caddy[2148]: 2017/08/18 11:11:03 [INFO][mydomain.example.com] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/xxxxxxxxxxx-xxxxxx
Aug 18 11:11:03 sheaf caddy[2148]: 2017/08/18 11:11:03 [INFO][mydomain.example.com] acme: Trying to solve TLS-SNI-01
Aug 18 11:11:04 sheaf caddy[2148]: 2017/08/18 11:11:04 [mydomain.example.com] failed to get certificate: [mydomain.example.com] error presenting token: Could not start HTTPS server for challenge -> listen tcp :443: bind: permission denied
Aug 18 11:11:04 sheaf systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Aug 18 11:11:04 sheaf systemd[1]: caddy.service: Unit entered failed state.
Aug 18 11:11:04 sheaf systemd[1]: caddy.service: Failed with result 'exit-code'.

My eye was immediately drawn to the permission denied on port 443, however I have used setcap to give the www-data user the appropriate capability:

root@sheaf:~# getcap /usr/local/bin/caddy
/usr/local/bin/caddy = cap_net_bind_service+ep

I’ve tried restarting the server but I get the same thing. There is nothing already running on port 80 or 443. Sometimes the error is identical except it says port 80. I CAN run the following command and Caddy will start and work properly, just not from systemd:

sudo -Hu www-data ./caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp

Here is my Caddyfile:

root@sheaf:~# cat /etc/caddy/Caddyfile 
mydomain.example.com {
	tls myemail@example.com
}

(I have replacing my actual domain name with example.com references for the post)

Can anyone spot what might be wrong?

Thanks,

- Bob -

1 Like
2

What happens if you uncomment these lines in the service file?

https://github.com/mholt/caddy/blob/master/dist/init/linux-systemd/caddy.service#L46-L48

3 Likes
3

When I uncomment those lines Caddy starts just fine:

root@sheaf:~# vim /etc/systemd/system/caddy.service

[make changes]

root@sheaf:~# systemctl daemon-reload
root@sheaf:~# systemctl restart caddy
root@sheaf:~# systemctl status caddy
● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled)
   Active: active (running) since Sun 2017-08-20 00:34:30 UTC; 3s ago
	 Docs: https://caddyserver.com/docs
 Main PID: 19747 (caddy)
	Tasks: 6 (limit: 4915)
   Memory: 1.7M
	  CPU: 48ms
   CGroup: /system.slice/caddy.service
	       └─19747 /usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp

Reverting those changes causes it to revert back to its prior failing state. What do you think is going on and why would I have to uncomment those lines?

Cheers,

Bob.

1 Like
4

Wow, I wasn’t necessarily expecting this to solve the issue, just a long shot to see what happened. My understanding was that setcap should be sufficient. Those lines are effectively doing the same thing as setcap (granting the required capabilities), but they also limit the service to only those capabilities, while being run as a service.

systemd is a bit of a black box to me sometimes. ¯\_(ツ)_/¯

5

Someone uncommented said three lines because they didn’t work for him/her/them using an even-then-obsolete systemd <v229. (I didn’t look up who did this. Generally speaking here.) You need capability CAP_NET_BIND_SERVICE to listen on ports ≤1000 (or ≤2000, depending on your system config).

In other words, don’t use the setcap bodge and uncomment these lines, as has been suggested by Whitestrake. :wink:

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.