Caddy Fails to Retrieve Certificates with DNS Challenge

Help
1

1. The problem I’m having:

I have been having trouble for some time now with getting certificates for my Caddy server. The configuration I had used to work fine, but maybe a month or so ago it stopped being able to retrieve new certificates. Initially I was using Namecheap as the DNS provider and had the issue, but eventually switched to Cloudflare as I planned to do so anyway, and still have been having the same issue.

This Caddy instance runs on my local network and reverse_proxies other things running on my local network, as subdomains of the main domain that I bought (e.g. example.com). I also have Pihole + Unbound and my router pointed at that.
It’s possible that it’s related to Pihole, as I think the timeline may have been a bit after I upgraded from v5 to v6, but I’m not positive, and Caddy is the one with the error messages so I’ll start there.’
I do remember seeing some relevant-looking comments about disabling propagation checks, but I wasn’t sure that they applied, and recent comments suggested that should have been solved in a version earlier than what I have.

2. Error messages and/or full log output:

I think this is the relevant line (with any specific information made more general), but I can post more logs as needed.

{"level":"error","ts":1749437463.0314894,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"subdomain.example.com",
"issuer":"acme-v02.api.letsencrypt.org-directory","error":"[subdomain.example.com] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challeng
e.subdomain.example.com\": unexpected response code 'REFUSED' for _acme-challenge.subdomain.example.com. (order=https://acme-v02.api.letsencrypt.org/acme/order/<MY_ORDER>) (ca=https://acme-v02.api.letsencrypt.org/directory)"}

3. Caddy version:

2.10.0

4. How I installed and ran Caddy:

Built with xcaddy (which was installed from Debian with package source added according to instructions), and copied to relevant directory as recommended by instructions.

a. System environment:

Debian 12 (Bookworm), non-Docker, no other relevant software changed from defaults installed with OS

b. Command:

Ran with systemd

/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force
EnvironmentFile=/etc/caddy/.env
TimeoutStopSec=5s
LimitNOFILE=1048576
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddy config:

The rest of the configuration has been working fine, and is mostly just some standard reverse_proxy blocks, this is the only thing that has changed recently.

acme_dns cloudflare {
		api_token {env.CF_API_TOKEN}
	}

5. Links to relevant resources:

2

If you check your Pihole logs for subdomain.example.com do you see anything being blocked?

IIRC that error is coming from the propagation check (where Caddy/certmagic is checking to see that the DNS record exists prior to asking the CA to validate), and if Caddy can’t resolve the zone, it won’t trigger the order.

4

Specifically referring to mc962’s mention of using Pihole for their local network, rather than a generic installation advice/recommendation.

5

Ooops. I was on the wrong topic. I deleted my post.

1 Like
6

Maybe something with the Cloudflare settings needed time to propagate, or I changed something else in my Caddyfile aside from the Cloudflare configuration, as I get the certificates downloaded now.

I do see a new error now, which from what I read isn’t a fatal error, but I never used to get it:

{"level":"warn","ts":1749615552.3989494,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [subdomain.example.com]: no OCSP server specified in certificate","identifiers":["subdomain.example.com"]}

Ideally I’d like to get rid of it, if there is something additional I need to configure at any point in Caddy/pihole/Cloudflare. I think from what I’ve read some say it’s transient but checking logs I think it’s been happening for a little while today.

This seems relevant https://github.com/caddyserver/caddy/issues/7023, and was marked as closed and linked to 2.10.1 (while I have 2.10.0), so it seems like maybe it’s fine and the log will go away in the next release?

7

I did just get this again, for a domain I recently added (let’s call it new_domain.example.com).

I noticed in the past that if I add a domain to Pihole → Cadddyfile, it can take up to maybe an hour or so for it to work properly (resolve properly from client → Pihole → Caddy).

I also see cached _acme-challenge.new_domain.example.com is NXDOMAIN in my Pihole logs when I try to get a new certificate, so maybe it will work when some pihole caches clear up.
Fortunately none of my other domains are having this issue so far, it’s just unfortunately an unclear error.