Caddy does not manage any automatic certificates

[RobLatour]

Using the OPNSense Caddy plug in - I can't seem to the automatic certificates to work.

I've followed and reviewed the instructions at https://docs.opnsense.org/manual/how-tos/caddy.html (several times) and watched the video at https://www.youtube.com/watch?v=6ip8Sx4zcDA many times, however, I can't seem to get automatic certificates to work.

screenshot of what I am getting on the dashboard: https://ibb.co/5TLqKzM
greyed out is my hostname . domain name - but it matches the hostname and domain name found in OPNSense - System - Settings - General.  For example:  router.example.com

Having that said, I do seem to have a valid certificate for the hostname . domain in system trust certificates - due to expire in December.  Not sure how it got there - I've tried many things, and prior to this I had been using the acme client (now uninstalled - so maybe it was created from there).   I am however hesitant to delete it from trust so that I could take a fresh run at all this; Regardless, I tried and it said it was being used by webgui and AcmeClient - validation for OPNSense router {AcmeClient.certificates.certificate.xxxx-xxxxx-xxx...-xxx}


My domain dns records look like this:

Name                        Type          TTL   RDATA 
@                             A           14400   xxx.xxx.xxx.xxx
@                             NS           86400   xxxx.ns.cloudflare.com
@                             NS           86400   xxxx.ns.cloudflare.com
www                         CNAME   14440   example.com
router.example.com   CNAME   14440   example.com
*.example.com          CNAME   14440   example.com

These are the errors I see in the log is:

Code: [Select]

2024-09-18T11:11:08-04:00 Error caddy "error","ts":"2024-09-18T15:11:08Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"router.example.com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:dns - DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain"}
2024-09-18T11:11:08-04:00 Error caddy "error","ts":"2024-09-18T15:11:08Z","logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"router.example.com","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]},"order":"https://acme-v02.api.letsencrypt.org/acme/order/1952357436/306227172126","attempt":2,"max_attempts":3}
2024-09-18T11:11:08-04:00 Error caddy "error","ts":"2024-09-18T15:11:08Z","logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"router.example.com","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]}}
2024-09-18T11:11:06-04:00 Error caddy "error","ts":"2024-09-18T15:11:06Z","logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"router.example.com","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]},"order":"https://acme-v02.api.letsencrypt.org/acme/order/1952357436/306227166306","attempt":1,"max_attempts":3}
2024-09-18T11:11:06-04:00 Error caddy "error","ts":"2024-09-18T15:11:06Z","logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"router.example.com","challenge_type":"http-01","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]}}
2024-09-18T11:11:04-04:00 Error caddy "error","ts":"2024-09-18T15:11:04Z","logger":"tls","msg":"job failed","error":"router.example.com: obtaining certificate: [router.example.com] Obtain: [router.example.com] solving challenges: [router.example.com] context canceled (order=https://acme.zerossl.com/v2/DV90/order/jmMN4DSlnzSi3PaZlGl9aQ) (ca=https://acme.zerossl.com/v2/DV90)"}
2024-09-18T11:11:04-04:00 Error caddy "error","ts":"2024-09-18T15:11:04Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"router.example.com","issuer":"acme.zerossl.com-v2-DV90","error":"[router.example.com] solving challenges: [router.example.com] context canceled (order=https://acme.zerossl.com/v2/DV90/order/jmMN4DSlnzSi3PaZlGl9aQ) (ca=https://acme.zerossl.com/v2/DV90)"}
2024-09-18T11:11:04-04:00 Error caddy "error","ts":"2024-09-18T15:11:04Z","logger":"tls.issuance.acme.acme_client","msg":"deactivating authorization","identifier":"router.example.com","authz":"https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw","error":"attempt 1: https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw: context canceled"}
2024-09-18T11:11:04-04:00 Error caddy "warn","ts":"2024-09-18T15:11:04Z","logger":"tls.issuance.acme.acme_client","msg":"HTTP request failed; retrying","url":"https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw","error":"performing request: Post \"https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw\": context canceled"}
Note: all references to example.com and router.example.com have been included above to safeguard privacy, the actual domain name is used on my system in real life.

When I make changes, I wait an hour - which is making this a long process, but have yet to have success so I though at this point it would be best to reach out for help.

Any help would be appreciated.

[Monviech (Cedrik)]

The log states it looks for A and AAAA records, it can only find CNAME though.

Better use DNS01 challenge with cloudflare and enable dyndns too for automatic domain name management.

If you want to use HTTP01 challenge make sure to create A records for all domains.

[RobLatour]

Thank you,

Originally, I did have an A record with a name of router.example.com pointing to my ip address - but it did not work; it was generating the same error messages in the logs.

Regardless, after reading your suggestion, I removed the two cname records:
router.example.com   CNAME   14440   example.com
*.example.com          CNAME   14440   example.com

and re-created an A record to replace it:
router.example.com   A             14440   xxx.xxx.xxx.xxx

and tried it again - by which I mean that I go in to OPNSense - Services: Caddy Web Server: Reverse Proxy, edit the domain record, don't make changes, save it, and clicked Apply (which I have found generates a series of log entries showing the error - which I take as the system is trying it again).

However, it generated the same error messages in the log.

Also, I had previously set up the Services: Caddy Web Server: General Settings - DNS Provider to use CloudFlare, and I pasted the API Tolken created as per this webpage walkthru https://homenetworkguy.com/how-to/replace-opnsense-web-ui-self-signed-certificate-with-lets-encrypt/ . 

This portion of my setup had remained unchanged when I ran the most recent attempt to get this working as refenced above.  Regardless, I have now since gone into Cloudflare and removed the existing DNS API entry and created a new one, and got the new token from that (as I believe somewhere I read the Cloudflare token can only be used once) which I then used to update within Services: Caddy Web Server: General Settings - DNS Provider.

I then tried it again (as explained above) but it still didn't work - same errors.

Dynamic DNS has been enabled throughout all of this.

Unless I get other feedback between now then, I will wait another hour (to wait past the one hour wait period between multiple failed certification request attempts ) and then recreate another CloudFlare token and try it again.

[Monviech (Cedrik)]

In your case the correct configuration for cloudflare would be:

DNS Provider: Cloudflare
APi Key: restricted API key for zone management
DNS Propagation: Resolvers: 1.1.1.1

First domain:
*.example.com
DNS Challenge: X
(you dont need dynamic DNS here)

Press Apply and Subdomain Menu shows up.

First Subdomain:
router.example.com
Dynamic DNS: X

etc...

For DNS challenge you dont need to set records manually.
Afterwards you can disable and enable caddy to try certificates again right away.

[RobLatour]

Thank you @Monviech - but it appears I'm still not there - to recap:

Services: Caddy Web Server: General Settings : DNS Provider tab
DNS Provider                        CloudFlare
DNS API Standard Field         my CloudFlare token is here
Resolvers                             1.1.1.1

Services: Caddy Web Server: Reverse Proxy : Domains tab
Enabled               checked
Domain                *.example.com
Port                     443
Dynamic DNS       unchecked (your comments above had an X, but also said '(you dont need dynamic DNS here' so I was unsure of this?
Custom Certificate   None
Access List              privatre_ipV4 Allow access from private IPV4 range  (from Docs)

Services: Caddy Web Server: Reverse Proxy : Subdomains tab
Enabled               checked
Domain                *.example.com 443
Subdomain           router.example.com
Dynamic DNS       checked

After that I disabled and enabled caddy to try certificates again.

Did not work.

Code: [Select]

2024-09-18T14:20:05-04:00 Error caddy "error","ts":"2024-09-18T18:20:05Z","logger":"tls.obtain","msg":"will retry","error":"[*.example.com] Obtain: [*.example.com] solving challenges: *.example.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme.zerossl.com/v2/DV90/order/OVH8CgD_qmLgyGglHeMUNA) (ca=https://acme.zerossl.com/v2/DV90)","attempt":1,"retrying_in":60,"elapsed":1.461963369,"max_duration":2592000}
2024-09-18T14:20:05-04:00 Error caddy "error","ts":"2024-09-18T18:20:05Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.example.com","issuer":"acme.zerossl.com-v2-DV90","error":"[*.example.com] solving challenges: *.example.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme.zerossl.com/v2/DV90/order/OVH8CgD_qmLgyGglHeMUNA) (ca=https://acme.zerossl.com/v2/DV90)"}
2024-09-18T14:20:04-04:00 Error caddy "error","ts":"2024-09-18T18:20:04Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.example.com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.example.com] solving challenges: *.example.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme-v02.api.letsencrypt.org/acme/order/1952357436/306264234986) (ca=https://acme-v02.api.letsencrypt.org/directory)"}

EDIT: I noticed you didn't say that I should specify a port on the Services: Caddy Web Server: Reverse Proxy : Domains tab so I removed it.  This changed the Sub Domains entry so I selected the domain as *.example.com  (not *.example.com 443 as it previously read) and tried it again.  Still not working.

[Monviech (Cedrik)]

I think you misread. You have to check "DNS-01 Challenge" for the "*.example.com" domain to activate that challenge type.

If it still doesn't work please post your Caddyfile.

Make /SURE/ you delete the API key from it and if you do not want to expose your domains generalize them.

https://docs.opnsense.org/manual/how-tos/caddy.html#wildcard-domain-with-subdomains

[RobLatour]

Thank you.

It worked!

You are my hero! 

[Patrick M. Hausen]

@monviech puzzled about HTTP not working with CNAME entries. Is this a Caddy specific feature? We use that with Dehydrated in our data centre all the time.

[Monviech (Cedrik)]

Great that it worked. 

@Patrick

Unsure here, I just read the logs and maybe its a Cloudflare specific thing. I personally also create CNAME entries. Guess it depends on how the zones are set up.