Caddy2 reverse-proxy with self-signed cert refuses to work

1. Caddy version (caddy version):

2.3.0

2. How I run Caddy:

Caddy is installed as a service with caddyfile in /etc/caddy
Caddy is supposed to proxy the output (Port 8888) of a dockerd Nextcloud instance to https/Port 443 with a self-signed cert for testing.

a. System environment:

Debian 10.7 (running as a VM) with a dockerd Nextcloud setup,
Caddy is installed as a systemd service directly (not dockerd) on the docker host.
The VM has a fixed local IP in my LAN.
Windows 10 client

b. Command:

service caddy start

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

nc-test.hfw18 {
        encode gzip zstd
        tls internal
        reverse_proxy 127.0.0.1:8888

        log {
                output file     /var/log/caddy_nc.log
                format single_field common_log
        }

        header {
                # enable HSTS
                Strict-Transport-Security max-age=31536000;
        }

        redir /.well-known/carddav /remote.php/dav 301
        redir /.well-known/caldav /remote.php/dav 301
}

3. The problem I’m having:

I’m trying to access the Nextcloud page on port 443, but Firefox/Chromium keep throwing ssl error “SSL_ERROR_INTERNAL_ERROR_ALERT”. Connecting directly to the Nextcloud on port 8888 is not a problem.

Do I have to worry about the sudo errors (see pasted output of ‘service caddy status’) when running Caddy as a systemd service?

4. Error messages and/or full log output:

Output of ‘service caddy status’:
Jan 20 09:08:16 debian-docker caddy[1384]: 2021/01/20 09:08:16 define JAVA_HOME environment variable to use the Java trust
Jan 20 09:08:16 debian-docker sudo[1392]: pam_unix(sudo:auth): conversation failed
Jan 20 09:08:16 debian-docker sudo[1392]: pam_unix(sudo:auth): auth could not identify password for [caddy]
Jan 20 09:08:16 debian-docker sudo[1392]: caddy : user NOT in sudoers ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/tee /usr/local/share/ca-certificates/Caddy_Local_Authority_-_2021_ECC_Root_260085191920187754335991439435632523912.crt
Jan 20 09:08:16 debian-docker caddy[1384]: {“level”:“error”,“ts”:1611130096.5906372,“logger”:“pki.ca.local”,“msg”:“failed to install root certificate”,“error”:“failed to execute sudo: exit status 1”,“certificate_file”:“storage:pki/authorities/local/root.crt”}
Jan 20 09:08:16 debian-docker caddy[1384]: {“level”:“info”,“ts”:1611130096.5909111,“logger”:“http”,“msg”:“enabling automatic TLS certificate management”,“domains”:[“nc-test.hfw18”]}
Jan 20 09:08:16 debian-docker caddy[1384]: {“level”:“warn”,“ts”:1611130096.591306,“logger”:“tls”,“msg”:“stapling OCSP”,“error”:“no OCSP stapling for [nc-test.hfw18]: no OCSP server specified in certificate”}
Jan 20 09:08:16 debian-docker caddy[1384]: {“level”:“info”,“ts”:1611130096.5914094,“logger”:“tls”,“msg”:“cleaned up storage units”}
Jan 20 09:08:16 debian-docker caddy[1384]: {“level”:“info”,“ts”:1611130096.5918684,“msg”:“autosaved config”,“file”:"/var/lib/caddy/.config/caddy/autosave.json"}
Jan 20 09:08:16 debian-docker caddy[1384]: {“level”:“info”,“ts”:1611130096.5921562,“msg”:“serving initial configuration”}

5. What I already tried:

Already successfully did a ‘sudo caddy trust’ and imported the Caddy root.crt from /var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crt into my Windows 10 client. Restarted the client and browsers.

6. Links to relevant resources:

Lots of posts here about reverse-proxy problems. Mostly related to missing certificate on connecting client…

Probably the cert isn’t trusted by your client. What is in the log when you enable debug mode?

Thanks for your reply!

I finally made it work by changing the internal domain “nc-test.hfw18” to the assigned static LAN IP 192.168.2.170. Also made some changes regarding overwrite_host and trusted proxies in the config.php of the Nextcloud instance.

The added/modified part of the Nextcloud config.php looks like this now:


‘trusted_domains’ =>
array (
0 => ‘192.168.2.170’,
1 => ‘nc-test.hfw18’,
),
‘overwrite.cli.url’ => ‘https://192.168.2.170’, # formerly: http://192.168.2.170:8888
‘trusted_proxies’ => ‘192.168.2.170’, # added
‘overwritehost’ => ‘192.168.2.170’, # added
‘overwriteprotocol’ => ‘https’, # added

I also tested these entries with the internal domain “nc-test.hfw18” with no success.

As I can see the self-signed cert wich I imported to my client was issued for the IP. Not for the internal domain which I added later on.

How would I change from the IP to the internal domain? If I changed back to the domain in the caddyfile, would caddy issue a new self-signed certificate related to that domain? What about the errors shown in my initial post regarding sudo and installing the cert? Which by the way only were thrown with the domain in the caddyfile. No errors after changing to IP.

Any advice is appreciated!

Yep. Well, signed by the internal CA (not exactly the same as self-signed, because there actually is a CA involved, even if it’s not a widely trusted one)

That’s because Caddy, when run as a systemd service with that service file, uses the caddy user, which isn’t a sudoer (i.e. doesn’t have full permissions). So Caddy tries to see if it can make itself a sudoer to install the root certs. If it’s not running interactively, then it just gives up and moves on.

Those messages are ultimately harmless, and if you’ve installed the root CA cert yourself manually, then you should be good to go.

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