New to Caddy, got some questions

1. The problem I’m having:

I recently moved to Caddy from NPM and enjoy it a lot. That being said i am completely new to Caddy and have three questions:

A. How do i force Caddy to only use port 443 as an entry point and completely ignore requests on port 80? I already map only port 443:443 in my docker compose file but i wonder if i also have to explicitly declare https in front of my domain in my Caddyfile?

Like this:

https://remote.redacted.pro {
        forward_auth authelia:9091 { 

Instead of:

remote.redacted.pro {
        forward_auth authelia:9091 { 

B. How to force Caddy to use only the TLS-ALPN challenge and skip any attempts of using the HTTP challenge since i am not mapping port 80 anyways.

C. I am getting a “failed to sufficiently increase receive buffer size” in my Caddy logs.
I suspect that i need

   cap_add:
     - NET_ADMIN

in my docker compose file, but i just want to make sure this is the reason for the warning in the logs.

Thank you for this great piece of software and keep up the good work!

2. Error messages and/or full log output:

2024-03-12T16:00:52.729332934Z INF ts=1710259252.7292664 msg=failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.

3. Caddy version:

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

a. System environment:

Docker

b. Command:


c. Service/unit/compose file:

    caddy:
        networks:
            konvei:
                ipv4_address: 172.18.0.2
        ports:
#            - 80:80
            - 443:443
            - 443:443/udp
        container_name: caddy
        restart: always
        volumes:
            - /home/admin/dockerdata/caddy/data:/data/caddy
            - /home/admin/dockerdata/caddy/logs:/var/log/caddy
            - /home/admin/dockerdata/caddy/config:/config/caddy
            - /home/admin/dockerdata/caddy/config/Caddyfile:/etc/caddy/Caddyfile
        environment:
            - TZ=Europe/Athens
        image: caddy:latest

d. My complete Caddy config:

{
        admin off
        email redacted@gmail.com
}

auth.redacted.pro {
        reverse_proxy http://authelia:9091
        log {
                output file /var/log/caddy/authelia.log
        }
}

redacted.pro www.redacted.pro {
        forward_auth authelia:9091 {
                uri /api/verify?rd=https://auth.konvei.pro/
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
        }
        reverse_proxy http://homepage:3000 {
        }
        log {
                output file /var/log/caddy/homepage.log
        }
}

port.redacted.pro {
        forward_auth authelia:9091 {
                uri /api/verify?rd=https://auth.konvei.pro/
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
        }
        reverse_proxy https://portainer:9443 {
                transport http {
                        tls_insecure_skip_verify
                }
        }
        log {
                output file /var/log/caddy/portainer.log
        }
}

info.redacted.pro {
        forward_auth authelia:9091 {
                uri /api/verify?rd=https://auth.konvei.pro/
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
        }
        reverse_proxy http://grafana:3080 {
        }
        log {
                output file /var/log/caddy/grafana.log
        }
}

vpn.redacted.pro {
        forward_auth authelia:9091 {
                uri /api/verify?rd=https://auth.konvei.pro/
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
        }
        reverse_proxy http://wireguard:51821 {
        }
        log {
                output file /var/log/caddy/wireguard.log
        }
}

remote.redacted.pro {
        forward_auth authelia:9091 {
                uri /api/verify?rd=https://auth.konvei.pro/
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
        }
        reverse_proxy http://meshcentral:444 {
        }
        log {
                output file /var/log/caddy/meshcentral.log
        }
}

db.redacted.pro {
        forward_auth authelia:9091 {
                uri /api/verify?rd=https://auth.konvei.pro/
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
        }
        reverse_proxy http://influxdb:8088
        log {
                output file /var/log/caddy/influxdb.log
        }
}

5. Links to relevant resources:

1 Like

If you’re using Docker, not publishing the port is enough.

But keep in mind that you’re also causing the ACME HTTP challenge to not work, which makes your setup slightly more brittle because you’re entirely relying on the ACME TLS-ALPN challenge; if Let’s Encrypt finds a bug with that challenge (which has happened in the past), they may disable that challenge temporarily while they fix it.

Why exactly do you want to turn off HTTP? Caddy sets up HTTP->HTTPS redirects anyway, there’s no harm in leaving it up, in fact it’s a benefit to users because they will get properly redirected if typing the domain in their browser without https://.

No, specifying https:// makes no difference because HTTPS is the default in Caddy. See Caddyfile Concepts — Caddy Documentation which describes the rules for site addresses.

You can configure the auto_https disable_redirects global option to have skip enabling the redirects (which cause an :80 server to get implicitly created for you).

Using the tls directive you can turn off a challenge:

tls {
	issuer acme {
		disable_http_challenge
	}
}

But like I said, why do you want to do this?

That might fix it, I forget. But you can probably just follow the instructions on the linked page in that warning, I think the settings on your host machine will affect your Docker containers too.

2 Likes

Thank you for the prompt reply,

The reason i am trying to disable any redirects or the http acme challenge is because i am the only person using the site and i prefer to limit the attack surface, as such i only have port 443 open within docker and the host firewall itself.

Considering this i see no reason of having Caddy trying to serve SSL certificates via the http challenge since this will never work anyways due to lack of port 80. The redirects are also of no use since i am always accessing the page via https. As a result of my minimalism obsession i prefer to disable/remove stuff that is not going to be used as long as stuff does not break in the process.

Initially i wanted to use the DNS SSL challenge (i had it that way on NPM) but seeing that i would need to build my own custom version of Caddy got me hesitant. Though i might take a deeper look into it. If you do have any suggestions or tips/links to a guide on how to build my own Caddy docker image with my DNS plugin please let me know.

Regarding the buffer size error, I will try:

  cap_add:
    - NET_ADMIN

and report back, otherwise i will follow the guide as you suggested.

Thank you for your time.

There’s no attack surface. If there was any kind of legitimate risk with having HTTP exposed, we wouldn’t do it by default in Caddy. Unfounded paranoia, I think.

It’s trivial:

1 Like

After enabling:

cap_add:
    - NET_ADMIN

the buffer size warnings seem to be gone from my logs.

Thanx for all the information and the link to the guide.

1 Like

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