Goal

Set up Caddy as the public-facing reverse proxy for a Dockerized Mailu mail server, with both services sharing the same Sectigo wildcard TLS certificate. The end result:

• https://my.richardapplegate.io/webmail and /admin are accessible through Caddy on public port 443.
• Mailu’s front container serves HTTPS internally on port 443 within the Docker network.
• SMTP, IMAP, and POP3 ports (465, 993, 995, 587) use the same Sectigo wildcard certificate.
• There are no port conflicts and no redirect loops.

---

How It Works

Running Caddy in front of Mailu introduces a dual-TLS architecture. Caddy terminates TLS for web traffic on public port 443 and then proxies requests to Mailu’s front container over an internal HTTPS connection. Mailu also needs its own copy of the certificate because its mail services (SMTP on port 465, IMAP on port 993, POP3 on port 995) terminate TLS directly — Caddy is not involved in mail protocol traffic.

The key challenge is avoiding redirect loops. When Mailu is configured with TLS_FLAVOR=cert, its front container enforces HTTPS on all connections. If Caddy proxies to Mailu over plain HTTP (http://front:80), Mailu responds with a redirect to HTTPS, which Caddy forwards to the client, which sends the request back to Caddy, creating an infinite loop. The fix is to have Caddy proxy to https://front:443 instead, so Mailu sees an HTTPS connection and serves the content directly.

Both Caddy and Mailu mount the same certificate files from a shared host path. This ensures that the certificate presented on port 443 (web) matches the certificate presented on ports 465, 993, and 995 (mail), which is important for clients that validate hostnames across protocols.

---

Configuration

1. Certificates on the Host

You need two files from your Sectigo wildcard certificate: the full chain and the private key. Store them in a stable host path that both Caddy and Mailu can mount as read-only volumes:

• /mnt/volumes/certs/fullchain.pem
• /mnt/volumes/certs/privkey.pem

Before proceeding, verify that the certificate and private key match by comparing their modulus hashes:

openssl x509 -noout -modulus -in fullchain.pem | openssl md5
openssl pkey -noout -modulus -in privkey.pem  | openssl md5

Both commands should output the same MD5 hash. If they do not match, the certificate and key are from different pairs and TLS will fail.

---

2. Caddy Docker Compose

Caddy publishes the public HTTP and HTTPS ports and mounts the certificate directory as read-only:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    networks:
      - caddy
    ports:
      - "80:80"
      - "443:443/tcp"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./data:/data
      - ./config:/config
      - /mnt/volumes/certs:/certs:ro
networks:
  caddy:
    external: true

The caddy network is defined as external so that other compose stacks (including Mailu) can join it.

---

3. Mailu Environment Variables (mailu.env)

These are the settings that must be correct for this setup to work:

DOMAIN=richardapplegate.io
HOSTNAMES=my,mail

PORTS=25,465,587,993,995,4190

TLS_FLAVOR=cert
TLS_CERT_FILENAME=fullchain.pem
TLS_KEYPAIR_FILENAME=privkey.pem

WEB_ADMIN=/admin
WEB_WEBMAIL=/webmail
WEBSITE=https://my.richardapplegate.io

Important notes:

• DOMAIN is the apex domain (richardapplegate.io), not a subdomain.
• HOSTNAMES contains labels only (my,mail) — do not include dots or the full domain.
• TLS_FLAVOR must be cert (not certs — this is a common mistake).
• Do not include ports 80 or 443 in the PORTS list. Caddy owns those ports publicly. Including them here will cause a port conflict.

---

4. Mailu Docker Compose — Networking and Certificate Mounts

4.1 Attach the front container to both networks

Mailu’s front container needs to be on two networks: the internal Mailu network (so it can communicate with the SMTP, IMAP, and other backend containers) and the external Caddy network (so Caddy can reach it for reverse proxying):

services:
  front:
    networks:
      - mailu
      - caddy

4.2 Mount the certificates into the containers that need them

At minimum, the front, smtp, and imap containers need the certificate files. The mount paths must match the filenames specified in TLS_CERT_FILENAME and TLS_KEYPAIR_FILENAME:

services:
  front:
    volumes:
      - /mnt/volumes/certs/fullchain.pem:/certs/fullchain.pem:ro
      - /mnt/volumes/certs/privkey.pem:/certs/privkey.pem:ro

  smtp:
    volumes:
      - /mnt/volumes/certs/fullchain.pem:/certs/fullchain.pem:ro
      - /mnt/volumes/certs/privkey.pem:/certs/privkey.pem:ro

  imap:
    volumes:
      - /mnt/volumes/certs/fullchain.pem:/certs/fullchain.pem:ro
      - /mnt/volumes/certs/privkey.pem:/certs/privkey.pem:ro

---

5. Caddyfile

Caddy terminates TLS for incoming web traffic and proxies to Mailu’s front container over internal HTTPS. This is the critical part — proxying to https://front:443 instead of http://front:80 is what prevents redirect loops:

my.richardapplegate.io {
  tls /certs/fullchain.pem /certs/privkey.pem

  # Optional: redirect the root path to webmail
  @root path /
  redir @root /webmail 302

  reverse_proxy https://front:443 {
    transport http {
      tls_server_name my.richardapplegate.io
      # Uncomment only if you encounter certificate chain issues:
      # tls_insecure_skip_verify
    }

    header_up Host {host}
    header_up X-Forwarded-Proto {scheme}
    header_up X-Forwarded-Host  {host}
    header_up X-Forwarded-For   {remote_host}
  }
}

Why proxy to HTTPS upstream? Because TLS_FLAVOR=cert tells Mailu’s front container to enforce HTTPS on all connections. If Caddy connects over plain HTTP, Mailu responds with a 301 redirect to HTTPS. The client follows the redirect back to Caddy, Caddy proxies over HTTP again, and the cycle repeats indefinitely. Connecting to https://front:443 avoids this entirely.

---

6. Restart Order

After making configuration changes, restart the services in this order. Mailu must come up first so that its front container is available when Caddy tries to proxy to it.

6.1 Restart Mailu

Use --force-recreate to ensure that environment variable and volume mount changes take effect:

cd /mnt/volumes/SamsungSSD970EVOPlus2TB/mailu
docker compose down
docker compose up -d --force-recreate

6.2 Reload Caddy

Reload the Caddyfile without restarting the container:

docker exec caddy caddy reload --config /etc/caddy/Caddyfile

---

7. Verification Tests

Run the following commands to confirm that every service is presenting the correct Sectigo wildcard certificate. All four tests should show CN=*.richardapplegate.io with a Sectigo issuer.

7.1 Web certificate (public port 443 via Caddy)

openssl s_client -connect my.richardapplegate.io:443 -servername my.richardapplegate.io </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

7.2 Mailu front certificate (internal, from inside the Caddy container)

docker exec caddy sh -lc \
'openssl s_client -connect front:443 -servername my.richardapplegate.io </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates'

7.3 SMTP TLS certificate (port 465)

openssl s_client -connect my.richardapplegate.io:465 -servername my.richardapplegate.io </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

7.4 IMAP TLS certificate (port 993)

openssl s_client -connect my.richardapplegate.io:993 -servername my.richardapplegate.io </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

All four commands should return the same certificate with CN=*.richardapplegate.io and a Sectigo issuer. If any test shows a different certificate or a self-signed certificate, check that the correct files are mounted into the corresponding container.