Unnecessary attempts to create new certs when using wildcards

1. The problem I’m having:

I’ve got a simple setup to reverse proxy some LAN servers using Caddy (I’m using lucaslorentz/caddy-docker-proxy but that isn’t important).

My Caddyfile is really simple at this point:

*.SECRET.duckdns.org {
tls {
dns duckdns {
api_token XXXXXXXXXXX
}
resolvers 8.8.8.8
}
}
home.SECRET.duckdns.org {
reverse_proxy XXX.XX.0.4:8123
}
SECRET.duckdns.org {
reverse_proxy XXX.XX.0.2:80
}

This works great! Chrome is happy etc.

However, looking at the logs, Caddy seems to be still going insane trying to issue a certificate for the specific subdomain home.secret.duckdns.org even though I’ve got a perfectly valid *.secret.duckdns.org certificate.

Is there a way to keep it from trying generate redudant certificates without having to put in the DNS challenge info into each request (it’s hard to do via lucaslorentz/caddy-docker-proxy)

2. Error messages and/or full log output:

2024-05-11T23:35:07.690412088Z ERR ts=1715470507.6901698 logger=tls.obtain msg=will retry error=[home.SECRET.duckdns.org] Obtain: [home.SECRET.duckdns.org] creating new order: attempt 1: https://acme.zerossl.com/v2/DV90/newOrder: HTTP 405: <html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.23.3</center>
</body>
</html>
 (ca=https://acme.zerossl.com/v2/DV90) attempt=3 retrying_in=120 elapsed=247.452595454 max_duration=2592000
2024-05-11T23:37:07.692299191Z INF ts=1715470627.6919837 logger=tls.obtain msg=obtaining certificate identifier=home.SECRET.duckdns.org
2024-05-11T23:37:07.868932827Z INF ts=1715470627.8685787 logger=tls.acme_client msg=trying to solve challenge identifier=home.SECRET.duckdns.org challenge_type=tls-alpn-01 ca=https://acme-staging-v02.api.letsencrypt.org/directory
2024-05-11T23:37:18.450231424Z ERR ts=1715470638.449843 logger=tls.acme_client msg=challenge failed identifier=home.SECRET.duckdns.org challenge_type=tls-alpn-01 problem={"type":"urn:ietf:params:acme:error:connection","title":"","detail":"24.130.63.166: Timeout during connect (likely firewall problem)","instance":"","subproblems":[]}
2024-05-11T23:37:18.450307291Z ERR ts=1715470638.449925 logger=tls.acme_client msg=validating authorization identifier=home.SECRET.duckdns.org problem={"type":"urn:ietf:params:acme:error:connection","title":"","detail":"24.130.63.166: Timeout during connect (likely firewall problem)","instance":"","subproblems":[]} order=https://acme-staging-v02.api.letsencrypt.org/acme/order/147846604/16465109884 attempt=1 max_attempts=3
2024-05-11T23:37:19.603514045Z INF ts=1715470639.6031568 logger=tls.acme_client msg=trying to solve challenge identifier=home.SECRET.duckdns.org challenge_type=http-01 ca=https://acme-staging-v02.api.letsencrypt.org/directory
2024-05-11T23:37:30.028582800Z ERR ts=1715470650.0282755 logger=tls.acme_client msg=challenge failed identifier=home.SECRET.duckdns.org challenge_type=http-01 problem={"type":"urn:ietf:params:acme:error:connection","title":"","detail":"24.130.63.166: Fetching http://home.SECRET.duckdns.org/.well-known/acme-challenge/mQLu_miJUBGjFT49VS9pAGxmFdYIyCI1aXCsmxinSrs: Timeout during connect (likely firewall problem)","instance":"","subproblems":[]}
2024-05-11T23:37:30.028702083Z ERR ts=1715470650.0283697 logger=tls.acme_client msg=validating authorization identifier=home.SECRET.duckdns.org problem={"type":"urn:ietf:params:acme:error:connection","title":"","detail":"24.130.63.166: Fetching http://home.SECRET.duckdns.org/.well-known/acme-challenge/mQLu_miJUBGjFT49VS9pAGxmFdYIyCI1aXCsmxinSrs: Timeout during connect (likely firewall problem)","instance":"","subproblems":[]} order=https://acme-staging-v02.api.letsencrypt.org/acme/order/147846604/16465112434 attempt=2 max_attempts=3
2024-05-11T23:37:30.028740066Z ERR ts=1715470650.0284736 logger=tls.obtain msg=could not get certificate from issuer identifier=home.SECRET.duckdns.org issuer=acme-v02.api.letsencrypt.org-directory error=HTTP 400 urn:ietf:params:acme:error:connection - 24.130.63.166: Fetching http://home.SECRET.duckdns.org/.well-known/acme-challenge/mQLu_miJUBGjFT49VS9pAGxmFdYIyCI1aXCsmxinSrs: Timeout during connect (likely firewall problem)
2024-05-11T23:37:34.705055579Z ERR ts=1715470654.7047536 logger=tls.obtain msg=could not get certificate from issuer identifier=home.SECRET.duckdns.org issuer=acme.zerossl.com-v2-DV90 error=[home.SECRET.duckdns.org] creating new order: attempt 1: https://acme.zerossl.com/v2/DV90/newOrder: HTTP 405: <html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.23.3</center>
</body>
</html>
 (ca=https://acme.zerossl.com/v2/DV90)
2024-05-11T23:37:34.705150200Z ERR ts=1715470654.704885 logger=tls.obtain msg=will retry error=[home.SECRET.duckdns.org] Obtain: [home.SECRET.duckdns.org] creating new order: attempt 1: https://acme.zerossl.com/v2/DV90/newOrder: HTTP 405: <html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.23.3</center>
</body>
</html>
 (ca=https://acme.zerossl.com/v2/DV90) attempt=4 retrying_in=300 elapsed=394.467310129 max_duration=2592000

3. Caddy version:

v2.7.6

4. How I installed and ran Caddy:

Docker-compose file (in Portainer)


version: "3.7"
services:
  caddy:
    build:
      context: .
      dockerfile_inline: |
        FROM caddy:builder-alpine AS builder

        RUN xcaddy build \
            --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
            --with github.com/caddy-dns/duckdns
        
        CMD ["caddy", "docker-proxy"]
          
    ports:
      - 80:80
      - 443:443
      - 2019:2019
    
      
    environment:
      - CADDY_INGRESS_NETWORKS=caddy
    networks:
      - caddy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - caddy_data:/data
      
    restart: unless-stopped

  whoami:
    image: traefik/whoami
    networks:
      - caddy
    
    env_file:
      - stack.env
      
    labels:

      caddy_0: "*.SECRET.duckdns.org"
      caddy_0.tls.dns: duckdns
      caddy_0.tls.resolvers: 8.8.8.8
      caddy_0.tls.dns.api_token: ${DUCKDNS_API_TOKEN}
     

      caddy_1: "SECRET.duckdns.org"
      caddy_1.reverse_proxy: "{{upstreams 80}}"

      
networks:
  caddy:
    external: true

volumes:
  caddy_data:


### a. System environment:
Linux, Portainer, Docker (version: 26.1.2)

You need to write your config like this:

It will be possible later to enable an option to prefer wildcard certs, see autohttps: Implement `auto_https prefer_wildcard` option by francislavoie · Pull Request #6146 · caddyserver/caddy · GitHub

1 Like

Yeah I’m really struggling to switch to that model. I cannot wait enough for the auto_https prefer_wildcard to be merged!