Timeouts when requesting Certificates with DNS challenge

1. Caddy version (caddy version): 2.5.0

2. How I run Caddy:

Docker on a Raspberry Pi 4B (8GB)

a. System environment:

Bullseye Light 64 Bit with Docker
also using pihole & unbound

b. Command:

`systemctl start caddy` and `systemctl reload caddy`

c. Service/unit/compose file:

root@raspberrypi:~# cat /lib/systemd/system/caddy.service
# caddy.service
#
# For using Caddy with a config file.
#
# Make sure the ExecStart and ExecReload commands are correct
# for your installation.
#
# See https://caddyserver.com/docs/install for instructions.
#
# WARNING: This service does not use the --resume flag, so if you
# use the API to make changes, they will be overwritten by the
# Caddyfile next time the service is restarted. If you intend to
# use Caddy's API to configure it, add the --resume flag to the
# `caddy run` command or use the caddy-api.service file instead.

[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
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

root@raspberrypi:~# caddy fmt /etc/caddy/Caddyfile
# global settings
{
        email hostmaster@b-struck.de
        grace_period 60s
}

# default template
(default) {
        tls {
                issuer acme {
                        dns netcup {
                                customer_number X
                                api_key "XX"
                                api_password "X"
                        }
                        propagation_timeout 30m
                        resolvers 1.1.1.1 8.8.8.8
                }
        }

        encode zstd gzip
        log {
                output file /var/log/caddy/{args.0}.log
        }

        header -Server
        header -X-Powered-By
        header ?Referrer-Policy no-referrer-when-downgrade
        header ?X-Content-Type-Options nosniff
        header ?X-Frame-Options SAMEORIGIN
        header ?Strict-Transport-Security max-age=31536000;
}

# site configs
nas.b-struck.de {
        import default nas.b-struck.de
        reverse_proxy 192.168.178.28:5000
}

pihole.b-struck.de, pi.b-struck.de {
        import default pihole.b-struck.de
        reverse_proxy 127.0.0.1:81
}

homebridge.b-struck.de, hb.b-struck.de {
        import default homebridge.b-struck.de
        reverse_proxy 127.0.0.1:8581
}

vault.b-struck.de {
        import default vault.b-struck.de
        reverse_proxy 127.0.0.1:500 {
                transport http {
                        tls
                        tls_insecure_skip_verify
                }
        }
}

3. The problem I’m having:

I have a problem with the certificate request. The domains should only be used internally.

4. Error messages and/or full log output:

I had first posted the log in here, but could not submit the post because the log contained too many characters (35k characters). Since I did not want to post anything incomplete here, I posted the log here:

https://zerobin.net/?bdfdd821769937c1#h6Aq5tZcOnjKsSpidxVdBjRh2JaXeDgM8nGC0SRumU4=

5. What I already tried:

At first I had the dns provider config first from the global settings, but then moved it to the site config because I wanted to set resolvers and propagation_timeout. I had entered in the configuration with the global config and the site config each at least 24h so and waited. There were also _acme-challenge.xyz.b-struck.de TXT records created at my domain, but they disappeared again before I got a cert.

6. Links to relevant resources:

Just using the Caddy documentation

1 Like

Thanks for posting the full logs!

This looks like a system misconfiguration, it was unable to reach the DNS resolvers to verify that the DNS record has been established before completing the challenge.

You can actually disable DNS propagation checks now in 2.5.0. You can set propagation_timeout -1 which will disable propagation checks. If your DNS provider is in fact setting the records properly and for some reason those checks are failing, you can disable them and should still be able to get a cert (but I advise only doing this if necessary – first, try to figure out what is causing your system to not connect to the resolver properly).

Hey Matt,

I tried your suggestion. The log is now a little smaller, but I’m running into errors again.

Attached is my changed config and my new log file

Caddyfile:

# global settings
{
        email hostmaster@b-struck.de
        grace_period 60s
}

# default template
(default) {
        tls {
                issuer acme {
                        dns netcup {
                                customer_number X
                                api_key "X"
                                api_password "X"
                        }
                        propagation_timeout -1m
                        resolvers 1.1.1.1 8.8.8.8
                }
        }

        encode zstd gzip
        log {
                output file /var/log/caddy/{args.0}.log
        }

        header -Server
        header -X-Powered-By
        header ?Referrer-Policy no-referrer-when-downgrade
        header ?X-Content-Type-Options nosniff
        header ?X-Frame-Options SAMEORIGIN
        header ?Strict-Transport-Security max-age=31536000;
}

# site configs
nas.b-struck.de {
        import default nas.b-struck.de
        reverse_proxy 192.168.178.28:5000
}

pihole.b-struck.de, pi.b-struck.de {
        import default pihole.b-struck.de
        reverse_proxy 127.0.0.1:81
}

homebridge.b-struck.de, hb.b-struck.de {
        import default homebridge.b-struck.de
        reverse_proxy 127.0.0.1:8581
}

vault.b-struck.de {
        import default vault.b-struck.de
        reverse_proxy 127.0.0.1:500 {
                transport http {
                        tls
                        tls_insecure_skip_verify
                }
        }
}

Log:

root@raspberrypi:~# journalctl -xn1000 | grep -iF 'caddy'
Mai 08 01:20:33 raspberrypi systemd[1]: Reloading Caddy.
â–‘â–‘ Subject: A reload job for unit caddy.service has begun execution
â–‘â–‘ A reload job for unit caddy.service has begun execution.
Mai 08 01:20:33 raspberrypi caddy[345773]: {"level":"info","ts":1651965633.1415908,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Mai 08 01:20:33 raspberrypi caddy[345773]: {"level":"warn","ts":1651965633.1487553,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":37}
Mai 08 01:20:33 raspberrypi caddy[345773]: {"level":"info","ts":1651965633.149,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Mai 08 01:20:33 raspberrypi caddy[345773]: {"level":"warn","ts":1651965633.1542926,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":37}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1568208,"logger":"admin.api","msg":"received request","method":"POST","host":"localhost:2019","uri":"/load","remote_ip":"127.0.0.1","remote_port":"43146","headers":{"Accept-Encoding":["gzip"],"Content-Length":["5362"],"Content-Type":["application/json"],"Origin":["http://localhost:2019"],"User-Agent":["Go-http-client/1.1"]}}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1604915,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.161085,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x4000188bd0"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1612828,"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}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1613379,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1641982,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["vault.b-struck.de","nas.b-struck.de","homebridge.b-struck.de","hb.b-struck.de","pihole.b-struck.de","pi.b-struck.de"]}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.164252,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/var/lib/caddy/.local/share/caddy"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.165938,"logger":"tls.obtain","msg":"acquiring lock","identifier":"vault.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.165938,"logger":"tls.obtain","msg":"acquiring lock","identifier":"nas.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.166268,"logger":"tls","msg":"finished cleaning storage units"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.166482,"logger":"tls.obtain","msg":"acquiring lock","identifier":"hb.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1671612,"logger":"tls.obtain","msg":"acquiring lock","identifier":"pi.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.167173,"logger":"tls.obtain","msg":"acquiring lock","identifier":"pihole.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.168554,"logger":"tls.cache.maintenance","msg":"stopped background certificate maintenance","cache":"0x4000308af0"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1686313,"logger":"tls.obtain","msg":"releasing lock","identifier":"vault.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1729188,"logger":"tls.obtain","msg":"releasing lock","identifier":"pi.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"error","ts":1651965633.1762955,"logger":"tls","msg":"job failed","error":"pi.b-struck.de: obtaining certificate: context canceled"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"error","ts":1651965633.1762955,"logger":"tls","msg":"job failed","error":"vault.b-struck.de: obtaining certificate: context canceled"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1766906,"msg":"autosaved config (load with --resume flag)","file":"/var/lib/caddy/.config/caddy/autosave.json"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.177879,"logger":"admin.api","msg":"load complete"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1785536,"logger":"tls.obtain","msg":"lock acquired","identifier":"nas.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.180537,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["nas.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1810873,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["nas.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.184076,"logger":"tls.obtain","msg":"lock acquired","identifier":"hb.b-struck.de"}
Mai 08 01:20:33 raspberrypi systemd[1]: Reloaded Caddy.
â–‘â–‘ Subject: A reload job for unit caddy.service has finished
â–‘â–‘ A reload job for unit caddy.service has finished.
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1840694,"logger":"tls.obtain","msg":"lock acquired","identifier":"pihole.b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1866918,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["hb.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1867971,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["hb.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1884913,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["pihole.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1885662,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["pihole.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:33 raspberrypi caddy[662]: {"level":"info","ts":1651965633.1958265,"logger":"admin","msg":"stopped previous server","address":"tcp/localhost:2019"}
Mai 08 01:20:34 raspberrypi caddy[662]: {"level":"info","ts":1651965634.1758087,"logger":"tls.obtain","msg":"lock acquired","identifier":"vault.b-struck.de"}
Mai 08 01:20:34 raspberrypi caddy[662]: {"level":"info","ts":1651965634.1775749,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["vault.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:34 raspberrypi caddy[662]: {"level":"info","ts":1651965634.1776865,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["vault.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:34 raspberrypi caddy[662]: {"level":"info","ts":1651965634.1795328,"logger":"tls.obtain","msg":"lock acquired","identifier":"pi.b-struck.de"}
Mai 08 01:20:34 raspberrypi caddy[662]: {"level":"info","ts":1651965634.180982,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["pi.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:34 raspberrypi caddy[662]: {"level":"info","ts":1651965634.1810555,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["pi.b-struck.de"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"hostmaster@b-struck.de"}
Mai 08 01:20:44 raspberrypi caddy[662]: {"level":"info","ts":1651965644.14132,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"nas.b-struck.de","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
Mai 08 01:20:49 raspberrypi caddy[662]: {"level":"info","ts":1651965649.4633894,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"pihole.b-struck.de","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
Mai 08 01:20:49 raspberrypi caddy[662]: {"level":"info","ts":1651965649.4838893,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"pi.b-struck.de","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
Mai 08 01:20:49 raspberrypi caddy[662]: {"level":"info","ts":1651965649.643373,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"vault.b-struck.de","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
Mai 08 01:20:49 raspberrypi caddy[662]: {"level":"info","ts":1651965649.6868215,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"hb.b-struck.de","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
Mai 08 01:20:55 raspberrypi caddy[662]: {"level":"error","ts":1651965655.3026807,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"nas.b-struck.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[nas.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702654506) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
Mai 08 01:20:55 raspberrypi caddy[662]: {"level":"error","ts":1651965655.3027549,"logger":"tls.obtain","msg":"will retry","error":"[nas.b-struck.de] Obtain: [nas.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702654506) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":22.124085119,"max_duration":2592000}
Mai 08 01:20:57 raspberrypi caddy[662]: {"level":"error","ts":1651965657.2055993,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"pihole.b-struck.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[pihole.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702668756) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
Mai 08 01:20:57 raspberrypi caddy[662]: {"level":"error","ts":1651965657.2056894,"logger":"tls.obtain","msg":"will retry","error":"[pihole.b-struck.de] Obtain: [pihole.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702668756) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":24.020199077,"max_duration":2592000}
Mai 08 01:20:57 raspberrypi caddy[662]: {"level":"error","ts":1651965657.5655115,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"pi.b-struck.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[pi.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702668796) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
Mai 08 01:20:57 raspberrypi caddy[662]: {"level":"error","ts":1651965657.566175,"logger":"tls.obtain","msg":"will retry","error":"[pi.b-struck.de] Obtain: [pi.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702668796) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":23.386596681,"max_duration":2592000}
Mai 08 01:20:57 raspberrypi caddy[662]: {"level":"error","ts":1651965657.9619868,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"vault.b-struck.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[vault.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702669046) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
Mai 08 01:20:57 raspberrypi caddy[662]: {"level":"error","ts":1651965657.9620585,"logger":"tls.obtain","msg":"will retry","error":"[vault.b-struck.de] Obtain: [vault.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702669046) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":23.786139306,"max_duration":2592000}
Mai 08 01:20:58 raspberrypi caddy[662]: {"level":"error","ts":1651965658.3005407,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"hb.b-struck.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[hb.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702669146) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
Mai 08 01:20:58 raspberrypi caddy[662]: {"level":"error","ts":1651965658.300667,"logger":"tls.obtain","msg":"will retry","error":"[hb.b-struck.de] Obtain: [hb.b-struck.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/525982367/86702669146) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":25.116506364,"max_duration":2592000}

Use -1, not -1m. The logic specifically looks for the value of -1. If you use -1m then it’s actually -60000000000, i.e. the amount of nanoseconds in a minute, which is not the same.

2 Likes

Hello Francis,

oops, sorry for my mistake. I have now changed the value from -1m to -1. Now waited just under an hour and attached the new log.

Because the log is again quite large with 46k characters, I uploaded it to zerobin.

https://zerobin.net/?95ae5d6d0b624657#V1J76huchOH/dYyHMYJN8QWn4UaY9vLybet3oBRr7b8=
1 Like

Well, it seems like your DNS provider plugin isn’t properly writing the TXT record.

netcup’s DNS nameserver usually take their sweet minute to propagate any DNS changes made.

This means that while you should see your new records in their dashboard/API, you might need to wait 10 minutes or more to be able to actually query them :zzz:
Most projects that interact with netcup’s nameservers recommend something along 900s (or more) as default timeout.

Also, netcup’s default TTL is insane (IIRC 24h) and can only be set globally for a whole zone :face_with_raised_eyebrow:

That said, those records should propagate eventually :woman_shrugging:
Interestingly, nas.b-struck.de managed to obtain a ZeroSSL certificate on 2022-05-05.
ZeroSSL is used as an issuer fallback, when LetsEncrypt fails.
See Automatic HTTPS — Caddy Documentation :innocent:

Did you try to query the TXT records when they were visible in netcup’s dashboard (dig, dog, nslookup, etc.)?

Furthermore, just to be sure, did you happen to change the global TTL very recently (read: since you tried to use the dns API with caddy)?

2 Likes

The TTL of my domain/zone was already set to 300s a few days before i started trying with caddy.
Also i queried the TXT Records multiple times when they were visible in the netcup dashboard with dig and also tried @1.1.1.1 and @8.8.8.8 (since i defined them as resolvers) and every time i got a reply showing the correct value, at least after a few minutes (3-5 at most). But caddy still reported the same i/o timeout error.

After setting the propagation_timeout -1 i also queried the dns and also got the correct reply, while caddy shows the No TXT record found value, as seen in the log i posted before.
I then stopped caddy, deleted all _acme-challenge TXT Records manually and started caddy again after about 30 minutes, but now no TXT Records seem to be set anymore and caddy only tries to continue the old challenges. I would like to force caddy to retry the whole process…

Also as Matt suggested in his first comment, i tried to figure out what would be causing my system to not connect to the resolver properly, but on the same system dig worked flawlessly and i never experienced any issues with DNS, just caddy reported those i/o timeouts when resolving…

1 Like

You can wipe Caddy’s storage then restart Caddy, and it should start fresh.

Since you’re running as a systemd service, Caddy’s storage is in /var/lib/caddy/.local/share/caddy

You can also configure propagation_delay to wait a certain amount of time before trying to grab the cert from the issuer. Try setting it to 5 or 10 minutes.

2 Likes

Hello,

I wanted to give a short feedback still. I removed the caddy folder last night as discussed and it’s been up and running since.

Thanks for the help :slight_smile:

2 Likes

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