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)