Unable to get wildcard certificate

1. The problem I’m having :

Quick recap : I cannot get a wildcard certificate, and I do not really understand the logs.
Edit 1 : One of the issues seems to have been solved

Hi ! I am trying to get a wildcard certificate for my domain using Caddy, but I am encountering errors that I am unable to interpret adequately. In particular I am unable to properly understand what this log means and what part of my setup is causing it :

{"level":"error","ts":1726295807.7741916,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"*.pfalz-zweibruecken.eu","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.pfalz-zweibruecken.eu\" (usually OK if presenting also failed)"}

I use Caddy for my home lab experiments, and as I am very new to this I am discovering the concepts revolving around Caddy as I « debug » my setup. At the moment I am just trying to get a wildcard certificate for my domain, so I have not dug into the reverse proxy part of it yet.

I have tried my best to try to solve the problem on my own without having to resort to this forum, so my apologises if the solution to this problem seems rather trivial ! I would also like to add that English is not my first language, so my explanations may not be as clear as I would like them to be.

2. Error messages and/or full log output:

Caddy  | {"level":"info","ts":1726351395.9387898,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Caddy  | {"level":"info","ts":1726351395.9451654,"msg":"adapted config to JSON","adapter":"caddyfile"}
Caddy  | {"level":"info","ts":1726351395.9593756,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
Caddy  | {"level":"info","ts":1726351395.9605906,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x400083a600"}
Caddy  | {"level":"info","ts":1726351395.9607377,"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}
Caddy  | {"level":"info","ts":1726351395.9607942,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
Caddy  | {"level":"info","ts":1726351395.9618063,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
Caddy  | {"level":"info","ts":1726351395.9628394,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
Caddy  | {"level":"info","ts":1726351395.9633424,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
Caddy  | {"level":"info","ts":1726351395.96341,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["*.pfalz-zweibruecken.eu"]}
Caddy  | {"level":"info","ts":1726351395.9649122,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
Caddy  | {"level":"info","ts":1726351395.964998,"msg":"serving initial configuration"}
Caddy  | {"level":"info","ts":1726351395.9682307,"logger":"tls.obtain","msg":"acquiring lock","identifier":"*.pfalz-zweibruecken.eu"}
Caddy  | {"level":"info","ts":1726351395.9682117,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"0e8742c4-5e12-498f-9ac2-72d3dc9b776b","try_again":1726437795.9682045,"try_again_in":86399.999997552}
Caddy  | {"level":"info","ts":1726351395.969346,"logger":"tls","msg":"finished cleaning storage units"}
Caddy  | {"level":"info","ts":1726351395.9733164,"logger":"tls.obtain","msg":"lock acquired","identifier":"*.pfalz-zweibruecken.eu"}
Caddy  | {"level":"info","ts":1726351395.9742613,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"*.pfalz-zweibruecken.eu"}
Caddy  | {"level":"info","ts":1726351395.9773896,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["*.pfalz-zweibruecken.eu"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"pfalz-kaiserslautern.spousal013@aleeas.com"}
Caddy  | {"level":"info","ts":1726351395.9774797,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["*.pfalz-zweibruecken.eu"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"pfalz-kaiserslautern.spousal013@aleeas.com"}
Caddy  | {"level":"info","ts":1726351395.9776306,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-v02.api.letsencrypt.org/acme/acct/1945760536","account_contact":["mailto:pfalz-kaiserslautern.spousal013@aleeas.com"]}
Caddy  | {"level":"info","ts":1726351397.0457633,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"*.pfalz-zweibruecken.eu","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
Caddy  | {"level":"error","ts":1726351397.1455142,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"*.pfalz-zweibruecken.eu","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.pfalz-zweibruecken.eu\" (usually OK if presenting also failed)"}
Caddy  | {"level":"error","ts":1726351397.314817,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.pfalz-zweibruecken.eu","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": Post \"https://ote.domrobot.com/jsonrpc/\": dial tcp: lookup ote.domrobot.com on 127.0.0.11:53: no such host (order=https://acme-v02.api.letsencrypt.org/acme/order/1945760536/305199599076) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
Caddy  | {"level":"error","ts":1726351397.3155138,"logger":"tls.obtain","msg":"will retry","error":"[*.pfalz-zweibruecken.eu] Obtain: [*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": Post \"https://ote.domrobot.com/jsonrpc/\": dial tcp: lookup ote.domrobot.com on 127.0.0.11:53: no such host (order=https://acme-v02.api.letsencrypt.org/acme/order/1945760536/305199599076) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":1.341861927,"max_duration":2592000}

3. Caddy version:

The Caddy image used by Docker is a custom image based on the 2.8.4-alpine version, with the inwx dns module added to it. The image was built following the Caddy documentation.

4. How I installed and ran Caddy:

A. System environment:

Caddy runs on Docker, installed on a Raspberry Pi Model B and whose OS is DietPi 9.7.1 version. There is at the moment only one container running alongside Caddy, and that is Technitium, although I did not set up Caddy to use the Technitium DNS server.
If I am not mistaken, DNS challenges do not require the domain to be externally accessible, and therefore although I have set up in the an A record pointing to my public IP address in the DNS records, I have not yet configured my router to forward port 80 and port 443 requests to my server.

B. Command:

sudo docker compose up -d caddy

C. Service/unit/compose file:

services:
  caddy:
    build: .
    container_name: Caddy
    cap_add:
      - NET_ADMIN
    ports:
      - 80:80
      - 443:443
      - 443:443/udp
    volumes:
      - /home/user/Docker/Caddy/Caddyfile:/etc/caddy/Caddyfile
      - /home/user/Docker/Caddy/site:/srv
      - /home/user/Docker/Caddy/data:/data
      - /home/user/Docker/Caddy/config:/config
    restart: unless-stopped
    networks:
      - Caddy

networks:
  Caddy:
    name: Caddy

D. My complete Caddy config:

(1) The dockerfile the docker-compose.yml uses to build the container

FROM caddy:2.8.4-builder-alpine AS builder

RUN xcaddy build \
 --with github.com/caddy-dns/inwx

FROM caddy:2.8.4-alpine

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

(2) The Caddyfile config

{
        email pfalz-kaiserslautern.spousal013@aleeas.com
}

*.pfalz-zweibruecken.eu {
        tls {
                dns inwx {
                        username redacted
                        password redacted
                        shared_secret redacted
                        endpoint_url https://ote.domrobot.com/jsonrpc/
                }
        }
}

5. Links to relevant resources :

The dns inwx module :

6. Updates

Thanks to @Bruce5051’s input, I was able to solve the Post \"https://ote.domrobot.com/jsonrpc/\": dial tcp: lookup ote.domrobot.com on 127.0.0.11:53: no such host issue.
Switching from https://ote.domrobot.com/jsonrpc/ (production environment) to https://api.ote.domrobot.com/jsonrpc/ (test environment) effectively solved the issue, although I stay unsure about the meaning of production and test environments.
Nonetheless the issue described in the introduction to this post persists.

Thank you in advance for the help !

Hi @Karl_V,

To me this is the place to start investigating:
ote.domrobot.com on 127.0.0.11:53: no such host

1 Like

Hi @Bruce5051, first of all thank you for your prompt reply !

I am not fluent in the syntax used by the logs, but so far I understand that there is a request being made to the internal Docker DNS server for the domain ote.domrobot.com, and there is no host associated with said server.
If I am not mistaken, by default the internal Docker DNS server uses the recursive DNS server specified in the /etc/resolv.conf file. Therefore my ISP’s DNS servers are used for this query.

I have used Wireshark to capture packets related to the Caddy container, and I have cross-referenced them with the logs from Caddy itself ; here are my findings :

The Caddy logs
caddy  | {"level":"error","ts":1726385695.8517742,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.pfalz-zweibruecken.eu","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": Post \"https://ote.domrobot.com/jsonrpc/\": dial tcp: lookup ote.domrobot.com on 127.0.0.11:53: no such host (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/163198603/19122947263) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}
caddy  | {"level":"error","ts":1726385695.852124,"logger":"tls.obtain","msg":"will retry","error":"[*.pfalz-zweibruecken.eu] Obtain: [*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": Post \"https://ote.domrobot.com/jsonrpc/\": dial tcp: lookup ote.domrobot.com on 127.0.0.11:53: no such host (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/163198603/19122947263) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":2,"retrying_in":120,"elapsed":62.672990913,"max_duration":2592000}

The time stamps correspond are 07:34:55.851 and 07:34:55.852.

The Wireshark logs
No.     Time                        Source                Destination           Protocol Length Info
66 2024/259 07:34:55.661978356 172.18.0.2            192.168.1.254         DNS      87     Standard query 0x53dc A ote.domrobot.com OPT
No.     Time                        Source                Destination           Protocol Length Info
67 2024/259 07:34:55.661978252 172.18.0.2            192.168.1.254         DNS      87     Standard query 0x2163 AAAA ote.domrobot.com OPT
No.     Time                        Source                Destination           Protocol Length Info
68 2024/259 07:34:55.671610179 192.168.1.254         172.18.0.2            DNS      144    Standard query response 0x53dc A ote.domrobot.com SOA ns.domrobot.com OPT
No.     Time                        Source                Destination           Protocol Length Info
69 2024/259 07:34:55.671755960 192.168.1.254         172.18.0.2            DNS      144    Standard query response 0x2163 AAAA ote.domrobot.com SOA ns.domrobot.com OPT
No.     Time                        Source                Destination           Protocol Length Info
70 2024/259 07:34:55.675521638 172.18.0.2            192.168.1.254         DNS      91     Standard query 0x6cd1 AAAA ote.domrobot.com.lan OPT
No.     Time                        Source                Destination           Protocol Length Info
71 2024/259 07:34:55.675521742 172.18.0.2            192.168.1.254         DNS      91     Standard query 0x8eb8 A ote.domrobot.com.lan OPT
No.     Time                        Source                Destination           Protocol Length Info
72 2024/259 07:34:55.683601742 192.168.1.254         172.18.0.2            DNS      166    Standard query response 0x8eb8 No such name A ote.domrobot.com.lan SOA a.root-servers.net OPT
No.     Time                        Source                Destination           Protocol Length Info
73 2024/259 07:34:55.683952888 192.168.1.254         172.18.0.2            DNS      166    Standard query response 0x6cd1 No such name AAAA ote.domrobot.com.lan SOA a.root-servers.net OPT

I have filtered some of the informations to keep it concise but the times tamps match quite well. So obviously there is a problem as my router does not give any IP associated with the domain the Caddy container is querying. And indeed, the endpoint specified in the Caddyfile config is unreachable. Quoting from the inwx module description :

If you don’t provide an endpoint_url the URL of the production environment (https://ote.domrobot.com/jsonrpc/) is used by default. If you want to use the test environment, set endpoint_url to https://api.ote.domrobot.com/jsonrpc/.

To be honest I do not really know the difference between a production environment and a test environment, but switching from https://ote.domrobot.com/jsonrpc/ to https://ote.domrobot.com/jsonrpc/ successfully solved the no host problem in the Caddy logs, and in the Wireshark logs show that there is indeed an IP returned with the query. Nevertheless the issue persists with the no memory of presenting a DNS record for \"_acme-challenge.pfalz-zweibruecken.eu\ error. Here are the new logs :

caddy  | {"level":"info","ts":1726387845.8101327,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
caddy  | {"level":"info","ts":1726387845.8160615,"msg":"adapted config to JSON","adapter":"caddyfile"}
caddy  | {"level":"info","ts":1726387845.8204668,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
caddy  | {"level":"info","ts":1726387845.8214827,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x400041e980"}
caddy  | {"level":"info","ts":1726387845.8219988,"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}
caddy  | {"level":"info","ts":1726387845.82208,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
caddy  | {"level":"info","ts":1726387845.823362,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
caddy  | {"level":"info","ts":1726387845.8247497,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
caddy  | {"level":"info","ts":1726387845.8254492,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
caddy  | {"level":"info","ts":1726387845.8255239,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["*.pfalz-zweibruecken.eu"]}
caddy  | {"level":"info","ts":1726387845.8288045,"logger":"tls.obtain","msg":"acquiring lock","identifier":"*.pfalz-zweibruecken.eu"}
caddy  | {"level":"info","ts":1726387845.8296251,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
caddy  | {"level":"info","ts":1726387845.8298109,"msg":"serving initial configuration"}
caddy  | {"level":"info","ts":1726387845.830222,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"0e8742c4-5e12-498f-9ac2-72d3dc9b776b","try_again":1726474245.8302145,"try_again_in":86399.999997343}
caddy  | {"level":"info","ts":1726387845.8307297,"logger":"tls","msg":"finished cleaning storage units"}
caddy  | {"level":"info","ts":1726387845.834097,"logger":"tls.obtain","msg":"lock acquired","identifier":"*.pfalz-zweibruecken.eu"}
caddy  | {"level":"info","ts":1726387845.834718,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"*.pfalz-zweibruecken.eu"}
caddy  | {"level":"info","ts":1726387845.8378122,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["*.pfalz-zweibruecken.eu"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"pfalz-kaiserslautern.spousal013@aleeas.com"}
caddy  | {"level":"info","ts":1726387845.8379018,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["*.pfalz-zweibruecken.eu"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"pfalz-kaiserslautern.spousal013@aleeas.com"}
caddy  | {"level":"info","ts":1726387845.8379786,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-v02.api.letsencrypt.org/acme/acct/1945760536","account_contact":["mailto:pfalz-kaiserslautern.spousal013@aleeas.com"]}
caddy  | {"level":"info","ts":1726387846.8662634,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"*.pfalz-zweibruecken.eu","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
caddy  | {"level":"error","ts":1726387850.2670715,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"*.pfalz-zweibruecken.eu","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.pfalz-zweibruecken.eu\" (usually OK if presenting also failed)"}
caddy  | {"level":"error","ts":1726387850.4285934,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.pfalz-zweibruecken.eu","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": (2200) Authentication error (order=https://acme-v02.api.letsencrypt.org/acme/order/1945760536/305310909166) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
caddy  | {"level":"error","ts":1726387850.4293342,"logger":"tls.obtain","msg":"will retry","error":"[*.pfalz-zweibruecken.eu] Obtain: [*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": (2200) Authentication error (order=https://acme-v02.api.letsencrypt.org/acme/order/1945760536/305310909166) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":4.595156092,"max_duration":2592000}
caddy  | {"level":"info","ts":1726387910.4348998,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"*.pfalz-zweibruecken.eu"}
caddy  | {"level":"info","ts":1726387910.4392142,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/163198603","account_contact":["mailto:pfalz-kaiserslautern.spousal013@aleeas.com"]}

At least, one of the two problems is solved, so thank you warmly for your help !

This just means some ACME issuer is repeatedly trying to fetch a challenge for that domain. Could just be some buggy behaviour in some issuer. If you managed to get a cert by now, you can ignore those, they’re harmless.

2 Likes

Hi, thanks for the reply !
Well, unfortunately after this line Caddy seems to keep trying to get the certificate, but to no avail.

caddy  | {"level":"info","ts":1726435624.7732384,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"*.pfalz-zweibruecken.eu"}
caddy  | {"level":"info","ts":1726435624.7777913,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/163198603","account_contact":["mailto:pfalz-kaiserslautern.spousal013@aleeas.com"]}
caddy  | {"level":"info","ts":1726435625.295003,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"*.pfalz-zweibruecken.eu","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
caddy  | {"level":"error","ts":1726435628.5063212,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"*.pfalz-zweibruecken.eu","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.pfalz-zweibruecken.eu\" (usually OK if presenting also failed)"}
caddy  | {"level":"error","ts":1726435628.6740758,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.pfalz-zweibruecken.eu","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": (2200) Authentication error (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/163198603/19136978213) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}
caddy  | {"level":"error","ts":1726435628.6749415,"logger":"tls.obtain","msg":"will retry","error":"[*.pfalz-zweibruecken.eu] Obtain: [*.pfalz-zweibruecken.eu] solving challenges: presenting for challenge: adding temporary record for zone \"pfalz-zweibruecken.eu.\": (2200) Authentication error (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/163198603/19136978213) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":4,"retrying_in":300,"elapsed":316.787803056,"max_duration":2592000}

Please forgive me if this is a dumb question, but is there anything else I should have configured apart from the setup indicated in my first post ? I have followed the steps explained in this post How to use DNS provider modules in Caddy 2, but I am still a bit lost as to whether or not I need to apply the steps specified in GitHub - caddy-dns/acmedns as well, especially adding a CNAME record in my DNS records ; do I also need to follow these ? Sorry to bother you !

Please use code blocks, not quotes, when posting logs and config. Use the </> button, not the " button. I edited your prefix post to fix it. Log text contains characters that get parsed as Markdown so it messes up the logs (e.g. * for italicized text).

“Authentication error” likely means your account key for your DNS provider was incorrect.

4 Likes

I have edited the rest of my posts, all logs and configs should now be using code blocks.
I am quite sure that I have filled in my credentials appropriately, and looking at this other post Example Caddyfile for acme w INWX / dns challenge, it seems that I was not the only one encountering this kind of issue. For now I have switched to Cloudflare for DNS hosting, and the certification process worked. I will open a ticket on the module’s Github page to see what may be wrong with the initial setup.

Anyway, thanks for the help !

2 Likes

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