# Can’t obtain lets encrypt certs with duckdns using docker compose caddy (unexpected response code 'SERVFAIL') **URL:** \ **Category:** Help\ **Created:** [November 2, 2024, 10:24pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133 "2024-11-02T22:24:58Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![opticlinkage](https://avatars.discourse-cdn.com/v4/letter/o/74df32/32.png) [@opticlinkage](https://vaultwarden.discourse.group/u/opticlinkage)\ **Post date:** [November 2, 2024, 10:24pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/1 "2024-11-02T22:24:58Z")
I am trying to follow [this guide](https://github.com/dani-garcia/vaultwarden/wiki/Using-Docker-Compose#caddy-with-dns-challenge) and [this guide](https://github.com/dani-garcia/vaultwarden/wiki/Running-a-private-vaultwarden-instance-with-Let%27s-Encrypt-certs) in order to have a private vaultwarden instance that is only accessible from within my internal LAN, but I want to utilise HTTPS from lets encrypt. I chose these guides as apparently it’s better to use a DNS challenge for this setup. I am running the following on a raspberry pi 4 on the latest kernel version. My router is a pfsense box that uses encrypted TLS quad9 as the DNS resolver. It also uses pfblocker but nothing comes up in the pfblocker logs when I try to obtain certs from lets encrypt using caddy. As far as I’m aware no outbound traffic is being blocked in pfsense. Here is my directory and the necessary files: ![docker folder](https://global.discourse-cdn.com/free1/uploads/vaultwarden/original/2X/e/e2af0546d95c77a2b932bedc807dfcd5b917e429.png) The caddy binary was [obtained from this link](https://caddyserver.com/download) where I selected **Linux arm64** and chose the duckdns download. I then renamed it to caddy. I also ran the file command on the caddy binary and it gives the following output: ```auto caddy: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=d2CUgHd5v5KarbWhll50/spUmDDdeK-sOxRIzlMTs/ODBKUlz7E8KeiCtYfzIm/dhB6KAm-bEo07d_o6xDW, stripped ``` The Caddyfile contains the following: ```auto {$DOMAIN} { log { level INFO output file {$LOG_FILE} { roll_size 10MB roll_keep 10 } } # Use the ACME DNS-01 challenge to get a cert for the configured domain. tls { dns duckdns {$DUCKDNS_TOKEN} } # This setting may have compatibility issues with some browsers # (e.g., attachment downloading on Firefox). Try disabling this # if you encounter issues. encode zstd gzip # Proxy everything to Rocket reverse_proxy vaultwarden:80 } ``` The docker compose file contains the following: ```auto services: vaultwarden: image: vaultwarden/server:latest container_name: vaultwarden restart: always environment: DOMAIN: "https://test111.duckdns.org" SIGNUPS_ALLOWED: "true" volumes: - ./vw-data:/data # the path before the : can be changed #ports: #- 8888:80 caddy: image: caddy:2 container_name: caddy restart: always ports: - 80:80 - 443:443 - 443:443/udp # Needed for HTTP/3. volumes: - ./caddy:/usr/bin/caddy - ./Caddyfile:/etc/caddy/Caddyfile:ro - ./caddy-config:/config - ./caddy-data:/data environment: DOMAIN: "test111.duckdns.org" #EMAIL: "admin@example.com" DUCKDNS_TOKEN: "" LOG_FILE: "/data/access.log" ``` I pulled the docker images and ran the containers. I then looked at the caddy docker logs: ```auto sudo docker logs -f caddy {"level":"info","ts":1727605355.2926478,"msg":"using config from file","file":"/etc/caddy/Caddyfile"} {"level":"info","ts":1727605355.2972434,"msg":"adapted config to JSON","adapter":"caddyfile"} {"level":"warn","ts":1727605355.2973034,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2} {"level":"info","ts":1727605355.3003426,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//[::1]:2019","//127.0.0.1:2019","//localhost:2019"]} {"level":"info","ts":1727605355.3008456,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x40005f9180"} {"level":"info","ts":1727605355.3009179,"logger":"http.auto_https","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} {"level":"info","ts":1727605355.3009539,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"} {"level":"info","ts":1727605355.3018198,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"} {"level":"info","ts":1727605355.3020425,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."} {"level":"info","ts":1727605355.3028066,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]} {"level":"info","ts":1727605355.30305,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]} {"level":"info","ts":1727605355.3030806,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["test111.duckdns.org"]} {"level":"info","ts":1727605355.3036702,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"} {"level":"info","ts":1727605355.3037133,"msg":"serving initial configuration"} {"level":"info","ts":1727605355.3042874,"logger":"tls.obtain","msg":"acquiring lock","identifier":"test111.duckdns.org"} {"level":"info","ts":1727605355.3129718,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"a16163dc-5a65-4977-a1d2-99f3861efde9","try_again":1727691755.312966,"try_again_in":86399.999998222} {"level":"info","ts":1727605355.3156607,"logger":"tls","msg":"finished cleaning storage units"} {"level":"info","ts":1727605355.317196,"logger":"tls.obtain","msg":"lock acquired","identifier":"test111.duckdns.org"} {"level":"info","ts":1727605355.3174765,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"} {"level":"info","ts":1727605355.3214889,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""} {"level":"info","ts":1727605355.3219013,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""} {"level":"info","ts":1727605355.3220537,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-v02.api.letsencrypt.org/acme/acct/1972895377","account_contact":[]} {"level":"info","ts":1727605356.633995,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"} {"level":"error","ts":1727605360.637146,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"test111.duckdns.org","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.test111.duckdns.org\" (usually OK if presenting also failed)"} {"level":"error","ts":1727605360.817957,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for _acme-challenge.test111.duckdns.org. (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309256751337) (ca=https://acme-v02.api.letsencrypt.org/directory)"} {"level":"error","ts":1727605360.8182611,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for _acme-challenge.test111.duckdns.org. (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309256751337) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":5.501031812,"max_duration":2592000} {"level":"info","ts":1727605420.8193543,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"} {"level":"info","ts":1727605420.8230555,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/165121373","account_contact":[]} {"level":"info","ts":1727605421.9944196,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"} {"level":"error","ts":1727605427.8644516,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"test111.duckdns.org","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.test111.duckdns.org\" (usually OK if presenting also failed)"} {"level":"error","ts":1727605428.0491064,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for test111.duckdns.org. (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19447977173) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"} {"level":"error","ts":1727605428.0493033,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111 .duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for test111.duckdns.org. (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19447977173) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":2,"retrying_in":120,"elapsed":72.732074094,"max_duration":2592000} ``` There are a few errors. I have tried the following: Ensuring the raspberry pi firewall is allowing the required ports: ```auto Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 51820/udp DENY Anywhere 10001/udp ALLOW Anywhere 8888/tcp ALLOW Anywhere 80 ALLOW Anywhere 443 ALLOW Anywhere 443/udp ALLOW Anywhere 443/udp (v6) ALLOW Anywhere (v6) ``` Ensuring the Caddyfile and caddy binary exist within the caddy container: ```auto sudo docker exec -it caddy ls /etc/caddy/ Caddyfile ``` ```auto sudo docker exec -it caddy /usr/bin/caddy version v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk= ``` Ensuring the caddy container environment variables are set: ```auto sudo docker exec -it caddy env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=095d14f91850 TERM=xterm DOMAIN=test111.duckdns.org DUCKDNS_TOKEN= LOG_FILE=/data/access.log CADDY_VERSION=v2.8.4 XDG_CONFIG_HOME=/config XDG_DATA_HOME=/data HOME=/root ``` Pinged [acme-v02.api.letsencrypt.org](http://acme-v02.api.letsencrypt.org) within the caddy container and raspberry pi host: ```auto sudo docker exec -it caddy ping acme-v02.api.letsencrypt.org PING acme-v02.api.letsencrypt.org (172.65.32.248): 56 data bytes 64 bytes from 172.65.32.248: seq=0 ttl=54 time=19.950 ms 64 bytes from 172.65.32.248: seq=1 ttl=54 time=19.783 ms 64 bytes from 172.65.32.248: seq=2 ttl=54 time=15.651 ms 64 bytes from 172.65.32.248: seq=3 ttl=54 time=15.698 ms 64 bytes from 172.65.32.248: seq=4 ttl=54 time=15.744 ms ``` ```auto ping acme-v02.api.letsencrypt.org PING ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com (172.65.32.248) 56(84) bytes of data. 64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=1 ttl=55 time=28.1 ms 64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=2 ttl=55 time=19.6 ms 64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=3 ttl=55 time=26.2 ms 64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=4 ttl=55 time=16.5 ms ``` Checked the duckdns api is working from the raspberry pi host: ```auto curl "https://www.duckdns.org/update?domains=test111&token=&ip=192.168.117.10" OK ``` Ensured my duckdns domain propagates with my private IP: ![dns map](https://global.discourse-cdn.com/free1/uploads/vaultwarden/original/2X/4/439db30bff9940d5dbe3250ba06a93148f060114.png) Other than that I have no idea why I’m getting the errors in the caddy docker log files. I also can’t access my vault warden instance with [test111.duckdns.org](http://test111.duckdns.org). If I un-comment the port setting for vaultwarden in the compose file I can access http unencrypted vaultwarden with the private IP address followed by the port. I did read some similar questions where the solution was to change the DNS resolver but I really want to avoid that as I wish to stick with quad9. EDIT: To add I also tried running the **Linux arm7** 32 bit custom caddy binary and got the following errors: ```auto file caddy caddy: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=xD1fJhezluuMbPrPc_Kq/OuJE28i4Dq5KmRaJN09u/vqkGaNKplMIedQakHLfX/5CNfhQwQuBK77Orkf_m_, stripped ``` ```auto sudo docker logs -f caddy {"level":"info","ts":1727622055.889434,"msg":"using config from file","file":"/etc/caddy/Caddyfile"} {"level":"info","ts":1727622055.8942316,"msg":"adapted config to JSON","adapter":"caddyfile"} {"level":"warn","ts":1727622055.8944693,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2} {"level":"info","ts":1727622055.8972685,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//[::1]:2019","//127.0.0.1:2019","//localhost:2019"]} {"level":"info","ts":1727622055.897921,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x3601440"} {"level":"info","ts":1727622055.8980148,"logger":"http.auto_https","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} {"level":"info","ts":1727622055.898221,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"} {"level":"info","ts":1727622055.8993847,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"} {"level":"info","ts":1727622055.8997521,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."} {"level":"info","ts":1727622055.900686,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]} {"level":"info","ts":1727622055.9010816,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]} {"level":"info","ts":1727622055.9011903,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["test111.duckdns.org"]} {"level":"info","ts":1727622055.9018955,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"} {"level":"info","ts":1727622055.9020681,"msg":"serving initial configuration"} {"level":"info","ts":1727622055.903311,"logger":"tls.obtain","msg":"acquiring lock","identifier":"test111.duckdns.org"} {"level":"info","ts":1727622055.9135754,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"a16163dc-5a65-4977-a1d2-99f3861efde9","try_again":1727708455.9135637,"try_again_in":86399.999995463} {"level":"info","ts":1727622055.9159403,"logger":"tls","msg":"finished cleaning storage units"} {"level":"info","ts":1727622055.9178913,"logger":"tls.obtain","msg":"lock acquired","identifier":"test111.duckdns.org"} {"level":"info","ts":1727622055.9184067,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"} {"level":"info","ts":1727622055.9393327,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""} {"level":"info","ts":1727622055.9394164,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""} {"level":"info","ts":1727622055.9394782,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-v02.api.letsencrypt.org/acme/acct/1972895377","account_contact":[]} {"level":"info","ts":1727622057.0690742,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"} {"level":"error","ts":1727622080.7703269,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309303011467) (ca=https://acme-v02.api.letsencrypt.org/directory)"} {"level":"error","ts":1727622080.7706964,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309303011467) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":24.852664933,"max_duration":2592000} {"level":"info","ts":1727622140.7757854,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"} {"level":"info","ts":1727622140.781972,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/165121373","account_contact":[]} {"level":"info","ts":1727622141.8062289,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"} {"level":"error","ts":1727622164.5756965,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19451462643) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"} {"level":"error","ts":1727622164.57607,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19451462643) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":2,"retrying_in":120,"elapsed":108.658033911,"max_duration":2592000} ``` EDIT 2: After leaving it for over a month I’m now getting no errors, but I still cannot access vaultwarden from my duck dns domain: ```auto sudo docker logs -f caddy {"level":"info","ts":1730509425.2111886,"msg":"using config from file","file":"/etc/caddy/Caddyfile"} {"level":"info","ts":1730509425.216362,"msg":"adapted config to JSON","adapter":"caddyfile"} {"level":"info","ts":1730509425.2219846,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]} {"level":"info","ts":1730509425.2253249,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x3305440"} {"level":"info","ts":1730509425.2259152,"logger":"http.auto_https","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} {"level":"info","ts":1730509425.2260175,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"} {"level":"info","ts":1730509425.2274652,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"} {"level":"info","ts":1730509425.2283056,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."} {"level":"info","ts":1730509425.2303185,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]} {"level":"info","ts":1730509425.2311358,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]} {"level":"info","ts":1730509425.2311902,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["test111.duckdns.org"]} {"level":"info","ts":1730509425.2411044,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"a16163dc-5a65-4977-a1d2-99f3861efde9","try_again":1730595825.2410927,"try_again_in":86399.999995389} {"level":"info","ts":1730509425.243545,"logger":"tls","msg":"finished cleaning storage units"} {"level":"info","ts":1730509425.2521818,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"} {"level":"info","ts":1730509425.252234,"msg":"serving initial configuration"} {"level":"info","ts":1730523225.9665465,"logger":"tls.issuance.acme.acme_client","msg":"got renewal info","names":["test111.duckdns.org"],"window_start":1732733817.6666667,"window_end":1732906617.6666667,"selected_time":1732735151,"recheck_after":1730544825.966436,"explanation_url":""} {"level":"info","ts":1730523225.971888,"logger":"tls.cache.maintenance","msg":"updated ACME renewal information","identifiers":["test111.duckdns.org"],"cert_hash":"473b1cf067496e9fc3f42fc415ea94d74e9283e57d31fe9d9a881f63aecb0ea3","ari_unique_id":"kydGmAOpUWiOmNbEQkjbI79YlNI.A6tlEWMRO5K6GadhyskBc19w","cert_expiry":1735411047,"selected_time":1732783719,"next_update":1730544825.966436,"explanation_url":""} ``` Also if I use nslookup to resolve my duck dns domain I get the following back: ```auto nslookup test111.duckdns.org ;; Got SERVFAIL reply from 127.0.0.53 Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find test111.duckdns.org: SERVFAIL ``` Any help is appreciated. ---
**Author:** ![BlackDex](https://yyz2.discourse-cdn.com/free1/user_avatar/vaultwarden.discourse.group/blackdex/32/8_2.png) [@BlackDex](https://vaultwarden.discourse.group/u/BlackDex)\ **Post date:** [November 3, 2024, 7:07pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/2 "2024-11-03T19:07:51Z")
Maybe next to ask at a caddy forum? I have no idea my self. ---
**Author:** ![undermemphis](https://avatars.discourse-cdn.com/v4/letter/u/47e85d/32.png) [@undermemphis](https://vaultwarden.discourse.group/u/undermemphis)\ **Post date:** [November 4, 2024, 6:15pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/3 "2024-11-04T18:15:47Z")
Try updating your tls section with this: ```auto tls { dns duckdns {$DUCKDNS_TOKEN} propagation_delay 30s propagation_timeout -1 } ``` ---
**Author:** ![Partridge2562](https://avatars.discourse-cdn.com/v4/letter/p/13edae/32.png) [@Partridge2562](https://vaultwarden.discourse.group/u/Partridge2562)\ **Post date:** [November 8, 2024, 2:46pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/4 "2024-11-08T14:46:55Z")
Have you seen [this caddy forum thread](https://caddy.community/t/is-dns-challenge-possible-with-freedns-afraid-org/26162/10) which mentions unreliable dns challenge with duckdns? If you try with certbot and/or acme.sh you may get better error messages than from caddy. ---
**Author:** ![opticlinkage](https://avatars.discourse-cdn.com/v4/letter/o/74df32/32.png) [@opticlinkage](https://vaultwarden.discourse.group/u/opticlinkage)\ **Post date:** [November 8, 2024, 5:00pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/5 "2024-11-08T17:00:25Z")
That’s interesting actually. I find that even doing an `nslookup` on my duck dns domain is hit or miss as to weather it resolves or not. I’m beginning to think the issue is duckdns. Thanks for your answer. I’ll have a look into it. ---
**Author:** ![opticlinkage](https://avatars.discourse-cdn.com/v4/letter/o/74df32/32.png) [@opticlinkage](https://vaultwarden.discourse.group/u/opticlinkage)\ **Post date:** [November 8, 2024, 5:01pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/6 "2024-11-08T17:01:42Z")
Yeah I think this issue is external to vaultwarden. Thanks though. ---
**Author:** ![opticlinkage](https://avatars.discourse-cdn.com/v4/letter/o/74df32/32.png) [@opticlinkage](https://vaultwarden.discourse.group/u/opticlinkage)\ **Post date:** [November 9, 2024, 5:24pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/7 "2024-11-09T17:24:08Z")
Hi there, I tried that and unfortunately it made no difference. ---
**Author:** ![opticlinkage](https://avatars.discourse-cdn.com/v4/letter/o/74df32/32.png) [@opticlinkage](https://vaultwarden.discourse.group/u/opticlinkage)\ **Post date:** [November 12, 2024, 5:05pm UTC](https://vaultwarden.discourse.group/t/can-t-obtain-lets-encrypt-certs-with-duckdns-using-docker-compose-caddy-unexpected-response-code-servfail/4133/8 "2024-11-12T17:05:47Z")
It turns out you have to [add a host override](https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-host-overrides.html) to Pfsenses DNS resolver settings so it can map your subdomain to a private IP on your LAN. With this I’m able to resolve my subdomain and also being able to load the vault warden webpage with the duckdns subdomain over SSL.