1. The problem I’m having:
In another thread, some advice was given about an :80 { ... } site block being bad due to how it affects HTTP => HTTPS redirects (from the default auto_https setting).
In seeking clarification on that, it was considered off-topic… hence this new thread (my config + commands from that thread are repeated below).
The response I received after was: WSS TLS handshake error - #5 by francislavoie
I am not sure what is being said here…? What is the problem with a domain that you’ve not configured not being redirected to HTTPS?
Here is what happens if I omit that block and follow the redirect:
$ curl http://caddy -L --insecure -v
curl: (35) OpenSSL/3.2.1: error:0A000438:SSL routines::tlsv1 alert internal error
$ curl http://caddy -L --insecure -v
* Host caddy:80 was resolved.
* IPv6: (none)
* IPv4: 172.28.0.3
* Trying 172.28.0.3:80...
* Connected to caddy (172.28.0.3) port 80
> GET / HTTP/1.1
> Host: caddy
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://caddy/
< Server: Caddy
< Date: Wed, 14 Aug 2024 13:32:18 GMT
< Content-Length: 0
<
* Closing connection
* Clear auth, redirects to port from 80 to 443
* Issue another request to this URL: 'https://caddy/'
* Host caddy:443 was resolved.
* IPv6: (none)
* IPv4: 172.28.0.3
* Trying 172.28.0.3:443...
* Connected to caddy (172.28.0.3) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* OpenSSL/3.2.1: error:0A000438:SSL routines::tlsv1 alert internal error
* Closing connection
curl: (35) OpenSSL/3.2.1: error:0A000438:SSL routines::tlsv1 alert internal error
That is the same if I were to have a https:// { ... } site block since no site address to match on for a cert.
If I have http://, https:// { ... } I can optionally reach HTTP without an implicit redirect, like I could http:// { ... } / :80 { ... } as shown below.
If this were to be an instance of Caddy bundled into an image like some might do with nginx/apache, it’s quite normal for that to just offer up port 80 / HTTP in favor of another reverse proxy that terminates TLS and routes to different containers.
The other use-case where you have explicit site addresses for other site blocks configured, we’ve clarified that as non-issue.
Main question
So why is it important to support HTTP => HTTPS redirects for site addresses that you don’t intend to have certificates for, nor respond to uniquely?
Could I please have an example / command that shows off the intended difference / benefit? I feel that I’m misunderstanding something or missing some context?
2. Error messages and/or full log output:
N/A
3. Caddy version:
2.8
4. How I installed and ran Caddy:
Docker Compose + WSL2
a. System environment:
Windows 11 + WSL2 (Ubuntu) + Docker Desktop
Docker Engine 26.1.1
v2.27
b. Command:
Two runs with redirects enabled/disabled were used to see what havoc :80 would wreck (but it was still not evident):
$ docker compose up --force-recreate
# Run a separate container on the same network to curl from and leverage container DNS
$ docker run --rm -it --network custom-network fedora
# HTTP => HTTPS redirect works:
$ curl -L --insecure http://example.test
Hello from https://example.test
# Caddy container also reachable via container_name:
$ curl -L --insecure http://caddy
Hello from port 80
# Repeat but this time with implicit redirects disabled:
$ AUTO_HTTPS='auto_https disable_redirects' docker compose up --force-recreate
$ docker run --rm -it --network custom-network fedora
# HTTP => HTTPS redirect disabled as expected:
$ curl -L --insecure http://example.test
Hello from port 80
# HTTPS still available directly as expected:
$ curl --insecure https://example.test
Hello from https://example.test
c. Service/unit/compose file:
# For the separate container to reference by name:
networks:
default:
name: custom-network
services:
reverse-proxy:
image: caddy:2.8
container_name: caddy
# Normally this would be `volumes`, but `configs` embeds config for a simple copy/paste `compose.yaml` example
configs:
- source: caddy-config
target: /etc/caddy/Caddyfile
# Support for requests from the Docker host like: `https://example.localhost`
ports:
- "80:80"
- "443:443"
# Containers on this network will resolve these aliases to the IP of this container:
networks:
default:
aliases:
- example.test
configs:
caddy-config:
content: |
{
local_certs
# Docker Compose ENV interpolation feature to toggle auto_https:
${AUTO_HTTPS:-}
}
:80 {
respond "Hello from port 80"
}
# `auto_https disable_redirects` would need require this for HTTP + HTTPS access:
#http://example.test, https://example.test {
example.test, example.localhost {
respond "Hello from {scheme}://{host}"
}
d. My complete Caddy config:
This is provided above embedded in the compose.yaml for easy reproduction. But here it is separately (comments stripped):
{
local_certs
}
:80 {
respond "Hello from port 80"
}
example.test, example.localhost {
respond "Hello from {scheme}://{host}"
}
