Caddy + Docker + DuckDNS -- ERR_SSL_PROTOCOL_ERROR

1. Caddy version (caddy version):

Latest (2.4.5)

2. How I run Caddy:

Docker Container w/ Portainer

a. System environment:

raspberryPi + Docker + Portainer

b. Command:

docker-compose setup via Portainer (see below)

c. Service/unit/compose file:

version: "3.7"

    image: caddy:latest
    container_name: caddy
    network_mode: "host"
      - 80:80
      - 443:443
      - /root/docker/caddy/config:/config
      - /root/docker/caddy/data:/data
      - /root/docker/caddy/Caddyfile:/etc/caddy/Caddyfile
    restart: unless-stopped

d. My complete Caddyfile or JSON config:

} {

3. The problem I’m having:

I can access my server using After running caddy, I am getting ERR_SSL_PROTOCOL_ERROR when accessing Logs show that it seems to get stuck on ‘trying to solve challenge’

4. Error messages and/or full log output:

2021-10-27T14:47:49.777141000Z {"level":"info","ts":1635346069.776511,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"},
2021-10-27T14:47:49.780706000Z {"level":"warn","ts":1635346069.7802675,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":5},
2021-10-27T14:47:49.804667000Z {"level":"info","ts":1635346069.801189,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["","localhost:2019","[::1]:2019"]},
2021-10-27T14:47:49.806490000Z {"level":"info","ts":1635346069.805974,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443},
2021-10-27T14:47:49.806884000Z {"level":"info","ts":1635346069.8061578,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"},
2021-10-27T14:47:49.818644000Z {"level":"info","ts":1635346069.8152685,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x40003ee000"},
2021-10-27T14:47:49.819371000Z {"level":"info","ts":1635346069.8184915,"logger":"http","msg":"enabling automatic TLS certificate management","domains":[""]},
2021-10-27T14:47:49.819866000Z {"level":"info","ts":1635346069.8190057,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"},
2021-10-27T14:47:49.820434000Z {"level":"info","ts":1635346069.8198602,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"},
2021-10-27T14:47:49.821047000Z {"level":"info","ts":1635346069.819946,"msg":"serving initial configuration"},
2021-10-27T14:47:49.821517000Z {"level":"info","ts":1635346069.8207166,"logger":"tls.obtain","msg":"acquiring lock","identifier":""},
2021-10-27T14:47:49.822947000Z {"level":"info","ts":1635346069.8225226,"logger":"tls","msg":"finished cleaning storage units"},
2021-10-27T14:47:49.844570000Z {"level":"info","ts":1635346069.8441617,"logger":"tls.obtain","msg":"lock acquired","identifier":""},
2021-10-27T14:47:49.847366000Z {"level":"info","ts":1635346069.8468802,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":[""],"ca":"","account":""},
2021-10-27T14:47:49.847923000Z {"level":"info","ts":1635346069.8470104,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":[""],"ca":"","account":""},
2021-10-27T14:47:50.469025000Z {"level":"info","ts":1635346070.468482,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"","challenge_type":"tls-alpn-01","ca":""},
2021-10-27T14:47:50.896728000Z {"level":"error","ts":1635346070.8960288,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"","challenge_type":"tls-alpn-01","status_code":400,"problem_type":"urn:ietf:params:acme:error:dns","error":"No valid IP addresses found for"},
2021-10-27T14:47:50.897346000Z {"level":"error","ts":1635346070.896273,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"","error":"authorization failed: HTTP 400 urn:ietf:params:acme:error:dns - No valid IP addresses found for","order":"","attempt":1,"max_attempts":3},
2021-10-27T14:47:52.112618000Z {"level":"error","ts":1635346072.1121552,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"","issuer":"","error":"HTTP 429 urn:ietf:params:acme:error:rateLimited - Error creating new order :: too many failed authorizations recently: see"},
2021-10-27T14:47:52.114215000Z {"level":"info","ts":1635346072.1134202,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":[""],"ca":"","account":""},
2021-10-27T14:47:52.114606000Z {"level":"info","ts":1635346072.113486,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":[""],"ca":"","account":""},
2021-10-27T14:47:52.569332000Z {"level":"info","ts":1635346072.5688822,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"","challenge_type":"http-01","ca":""}

5. What I already tried:

  • Tried different dockerfiles and setups.
  • Tried running caddy through command line – caddy reverse-proxy --from --to
  • Tried changing to localhost in Caddyfile and command line
  • Tried running caddy locally (without docker). Faced same issue/error.
  • Tried commenting-out email and tls portions from Caddyfile
  • Tried removing ‘network_mode’ propery from docker-compose file
  • Tried replacing tls with:
tls {
	dns duckdns {DUCKDNS_API_TOKEN}
  • I can see port 80 and 443 in port forwarding list in the router.
  • I’ve added IP to duckdns entry.

6. Links to relevant resources:

After trying a lot of things, I think my issue has something to do with duckdns provider (GitHub - caddy-dns/duckdns: Caddy module: dns.providers.duckdns). When I add the tls with duckdns token, I was getting the following error Error during parsing: getting module named 'dns.providers.duckdns'. Where should the downloaded repo be put for docker?

Seems like this subdomain doesn’t point to a valid public IP address.

$ host has address mail is handled by 50

You need to make sure the DNS points to your WAN (public) IP address, not your LAN (private) IP address.

You only need to use the DNS plugin if your server is not publicly accessible, or if you need wildcard certificates. It’s probably not necessary for you in this case.

If you find that you do need the DNS plugin though, you need to make a build of Caddy with the plugin added. See the docs on Docker Hub, specifically the section “Adding custom Caddy modules”

Is WAN IP address the IPv4 value that I see when I go to Also, do I change it only in duckdns subdomain and keep it as in Caddyfile?

It continues to get stuck at "logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge"


Be aware you IP address may not be static, and might change whenever your ISP feels like it. Best to run a dynamic DNS updater script (see the docs on the DuckDNS site for some examples), or install the GitHub - mholt/caddy-dynamicdns: Caddy app that keeps your DNS records (A/AAAA) pointed at itself. plugin which can automatically keep your DuckDNS IP address updated (also requires the DuckDNS plugin as mentioned above)

The IP address in your Caddyfile is the address that Caddy connects to when talking to your upstream service (by the port number, I assume Jellyfin). That should be the LAN IP to reach your service. If it’s running on the same machine, you can probably just use localhost or instead.

I changed it only in duckdns subdomain, and kept in Caddyfile.

In caddy logs, I see it continues to get stuck at "logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge"

Also, can the module building be done inside a docker-compose file?

FROM caddy:latest-builder AS builder

RUN xcaddy build \
    --with \

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy # where should this path be?

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