Using external ACME client

Help
1

1. Caddy version (caddy version):

caddy;latest

2. How I run Caddy:

a. System environment:

Docker container on Debian 11

b. Command:

docker-compose up -d

c. Service/unit/compose file:

  caddy:
    container_name: caddy-proxy-web
    image: caddy:latest
    restart: unless-stopped
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy/data:/data
      - ./caddy/config:/config
      - /var/log/caddy:/caddylog
      - /var/www/dehydrated:/acme
    ports:
      - 80:80
      - 443:443

d. My complete Caddyfile or JSON config:

{
        servers :443 {
                protocol {
                        experimental_http3
                }
        }
        log {
                level info
                output file /caddylog/caddy.log {
                        roll_size 1000MiB
                        roll_keep 20
                        roll_keep_for 2100h
                }
        }

}
dmg.io:80,  test.dmg.io;80 {
   #     tls {
   #             issuer acme {
   #                     disable_http_challenge
  #                      disable_tlsalpn_challenge
 #                       alt_http_port 81
#                }
#        }
        handle /.well-known/acme-challenge {
                root /.well-known/acme-challenge/* /acme

                file_server     
        }
}

3. The problem I’m having:

I want to use: a) a cert with dmg.io AND test.dmg.io in same certificate. But caddy splits it in seperate.
or
b) a external acme client. But caddy does not proxy /.well-known/acme-challenge to the directory. Instead it fails in the log.

4. Error messages and/or full log output:

{"level":"error","ts":1638647127.4962814,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"dmg.io","error":"no information found to solve challenge for identifier: dmg.io"}
{"level":"error","ts":1638647127.4965923,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"dmg.io","error":"no information found to solve challenge for identifier: dmg.io"}

5. What I already tried:

the lines with # in the caddyfile.
I found some entries on Github and this forum for this problem but for caddy 1 not for caddy 2.

6. Links to relevant resources:

2

Caddy doesn’t issue multi-SAN certificates, because there’s a bunch of problems with those that make it not ideal.

Why do you need a multi-SAN cert? Browsers don’t care if two different domains have different certificates.

See this write-up for more details: docs/acme-ops.md at master · https-dev/docs · GitHub

Caddy puts its own the route handling for that path in front of the routes defined in your config.

There’s rarely ever a good reason to use another ACME client behind Caddy for the HTTP challenge, so that was a design decision that was made.

3

The certificate is not for caddy but for another program that does only accept one cert for all domains. (not my choice, I just need a cert for it)

Is there any way to disable the route from caddy?

Thanks for your help!

4

Caddy will pass thru HTTP challenges for domains it isn’t configured to manage certs for. (But it can’t proxy TLS-ALPN challenges because it is not a TCP proxy by default, you’d need GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy which can do it. otherwise Caddy terminates TLS.)

I’m not sure why caddy is trying to solve those challenges. You sure you’re running with the right config? What’s the full log output? You only gave us two lines.

5

Hmm, well looking at this again, this block won’t match challenge requests. Path matching in Caddy is exact, so /.well-known/acme-challenge will only match that path exactly. Try this instead:

        handle /.well-known/acme-challenge* {
                root * /acme
                file_server
        }
1 Like
6

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