Issue on docs

[cmj01]

Path: /self-host/advanced/wild-card-domains

I think this guide is a little bit out of date now and Cloudflare have changed some of the DNS environment variables.

Lots of people seem to struggle with this so a new updated guide would be fantastic.

I'm still not clear whether I need Cloudflare Advanced Certificate Manager or not.

[oschwartz10612]

@LaurenceJJones could you take a look when you get a chance?

[AstralDestiny]

You don't need advanced cert unless you're planning to use proxied and ask for more then one wildcard in a nested subdomain,

as for the env part I would always use Key=value over key: value as compose will sometimes assume differently for a key, key=value says "Everything past this just throw to the container" vs key: value "Parse this and apply any formatting on special characters if they exist them dump to container"

Also for the Env it's still up to date. https://go-acme.github.io/lego/dns/cloudflare/

[AstralDestiny]

@cmj01 can you explain what part you seem to be struggling with or others? You don't need to pay cloudflare for anything if you want to use dns validation for wildcard certs.

[cmj01]

Thanks, appreciate the help.
I followed everything in the Pangolin guide and was still getting http individual certs. Very similar to this issue: https://github.com/fosrl/pangolin/issues/1829

So the questions I have are.

1. docker-compose.yml
    environment:
#      CLOUDFLARE_DNS_API_TOKEN: "blablabla"  
      - CF_DNS_API_TOKEN="blablabla" # <<- using new cloudflare variable and referencing as suggested

2. config/config.yml

domains:
    domain1:
        base_domain: "example.com"

added 17.05.2026 for cloudflare wildcard certificates

        cert_resolver: "letsencrypt" # <-- this was missing for me, and step 4 of guide just says to pref_wildcard

this is duplicated with flags below

        prefer_wildcard_cert: true # <-- should this be here on in the flags section?

Should this be in the flags section the bottom?

flags:
    require_email_verification: true
    disable_signup_without_invite: true
    disable_user_create_org: false
    allow_raw_resources: true
    prefer_wildcard_cert: true # <-- is this needed here

3. traefik_config.yml

are resolvers needed or not? I added based on config from others.

certificatesResolvers:
  letsencrypt:
    acme:
      dnsChallenge:
        provider: "cloudflare"
        resolvers:
          - "1.1.1.1:53"
          - "1.0.0.1:53"

also other guides seem to have this config but not sure if this is handled elsewhere now

also some other things I am not sure if needed or not like:
delayBeforeCheck: 5

and I have seen a few people add this sort of config too
domains:
- main: "foo.net"
sans:
- ".foo.net"
- ".home.foo.net"
- "*.lab.foo.net"

Many thanks again - I would love to get this working. At this point I'm just changing random stuff out of desperation!

Mike

[AstralDestiny]

not under flags,

So if not in UI,

domains:
  domain1:
    base_domain: domain1.com
    cert_resolver: cloudflare
    prefer_wildcard_cert: true
  domain2:
    base_domain: domain2.com
    cert_resolver: cloudflare
    prefer_wildcard_cert: true
  domain3:
    base_domain: domain3.net
    cert_resolver: cloudflare
    prefer_wildcard_cert: true
  domain4:
    base_domain: domain4.com
    cert_resolver: hetzner
    prefer_wildcard_cert: true

Which aligns to,

certificatesResolvers:
  http:
    acme:
      storage: acme.json
      httpChallenge:
        entryPoint: http
  cloudflare:
    acme:
      storage: acme.json #this will be different path for you.
      keyType: 'EC384'
      dnsChallenge:
        provider: cloudflare
        resolvers:
          - "1.1.1.1:53"
          - "1.0.0.1:53"
# others

If in ui you want the actual ui to prefer wildcards,

traefik:
  cert_resolver: "letsencrypt-dns" # align with the certificate resolvers 
  prefer_wildcard_cert: true

For example mine looks like,

traefik:
  cert_resolver: cloudflare
  http_entrypoint: http
  https_entrypoint: https
  prefer_wildcard_cert: true

as per the image above.

As for your last part you can nest as many wildcards up to 50 sans, Just no *.*.domain.com as that's not valid in dns so certs won't let you take those.

and for the ENV,

services:
  traefik:
    image: traefik:v3
    environment:
      - CF_DNS_API_TOKEN=keyhere

Make sure it's under traefik and not gerbil or others, and do a down and up and not just an up.

[AstralDestiny]

delayBeforeCheck: 5 That's if you have odd occurrences like for some odd reason it can't find the dns entry within a reasonable time even if it forces checks.. but since you're using cloudflare and using their official resolvers you likely don't need it, What I have above is how I have mine. Be curious where you got the info to put it into flags?

[AstralDestiny]

You do ned to put stuff in traefik_config, traefik_dynamic and the env and into the config.yml as per the docs. Sorry typed a bit on the phone some not. https://docs.pangolin.net/self-host/advanced/wild-card-domains

If still getting http certs, down the stack remove acme.json bring up the stack

[cmj01]

Some progress - I don't get an error initially

but when I create a simple local service

traefik | 2026-05-18T10:29:10Z INF Testing certificate renew... acmeCA=https://acme-v02.api.letsencrypt.org/directory providerName=letsencrypt-dns.acme
traefik | 2026-05-18T10:31:50Z ERR EntryPoint doesn't exist entryPointName=http routerName=2-openspeedtest-router-redirect@http
traefik | 2026-05-18T10:31:50Z ERR No valid entryPoint for this router routerName=2-openspeedtest-router-redirect@http
traefik | 2026-05-18T10:31:50Z ERR EntryPoint doesn't exist entryPointName=https routerName=2-openspeedtest-router@http
traefik | 2026-05-18T10:31:50Z ERR No valid entryPoint for this router routerName=2-openspeedtest-router@http
traefik | 2026-05-18T10:31:50Z ERR EntryPoint doesn't exist entryPointName=https routerName=2-openspeedtest-router@http
traefik | 2026-05-18T10:31:50Z ERR No valid entryPoint for this router routerName=2-openspeedtest-router@http
traefik | 2026-05-18T10:31:51Z ERR Unable to obtain ACME certificate for domains error="unable to generate a certificate for the domains [.example.xyz]: error: one or more domains had a problem:\n[.example.xyz] [.example.xyz] acme: error presenting token: cloudflare: failed to find zone example.xyz.: [status code 400] 6003: Invalid request headers; 6111: Invalid format for Authorization header\n" ACME CA=https://acme-v02.api.letsencrypt.org/directory acmeCA=https://acme-v02.api.letsencrypt.org/directory domains=[".example.xyz"] providerName=letsencrypt-dns.acme routerName=2-openspeedtest-router@http rule=Host(openspeedtest.example.xyz)

I've double checked the cloudflare API and everything seems right - not sure why it's complaining about the zone

Any ideas what to try next?

Thanks,

Mike

[cmj01]

I've attached domain redacted files here in case you can see what is missing..

I'm not using Cloudflare proxy - the DNS entries are just straight pointers.

[AstralDestiny]

If anything it's likely your qoutes there in the env as = takes anything past the equals..

(sorry half distracted irl)

Where'd you make the token? https://dash.cloudflare.com/profile/api-tokens here or account level? haven't had much luck with account tokens sometimes they read as valid then later theyjust error out about zoning issues. also just,
Zone / Zone / Read
Zone / DNS / Edit

And don't put "" if you're using the = one,

Your traefik: part needs to be web and websecure to match your entrypoints.

also throw traefik into TRACE logs and down and up should tell you in a lot more detail.

[cmj01]

Thanks - making progress I think!

Yes token created at account level via profile.

Now something seems to be happier with your suggested changes above with a few warnings - not sure how important they are:

traefik | 2026-05-18T11:37:58Z INF Loading plugins... plugins=["badger"]
traefik | 2026-05-18T11:37:58Z INF Plugins loaded. plugins=["badger"]
traefik | 2026-05-18T11:37:58Z INF Starting provider aggregator *aggregator.ProviderAggregator
traefik | 2026-05-18T11:37:58Z INF Starting provider *file.Provider
traefik | 2026-05-18T11:37:58Z INF Starting provider *traefik.Provider
traefik | 2026-05-18T11:37:58Z INF Starting provider *acme.ChallengeTLSALPN
traefik | 2026-05-18T11:37:58Z INF Starting provider *http.Provider
traefik | 2026-05-18T11:37:58Z INF Starting provider *acme.Provider
traefik | 2026-05-18T11:37:58Z INF Testing certificate renew... acmeCA=https://acme-v02.api.letsencrypt.org/directory providerName=letsencrypt.acme
traefik | 2026-05-18T11:37:58Z INF Starting provider *acme.Provider
traefik | 2026-05-18T11:37:58Z INF Testing certificate renew... acmeCA=https://acme-v02.api.letsencrypt.org/directory providerName=letsencrypt-dns.acme
pangolin | (node:27) [DEP0169] DeprecationWarning: url.parse() behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for url.parse() vulnerabilities.
pangolin | (Use node --trace-deprecation ... to show where the warning was created)
gerbil | INFO: 2026/05/18 11:38:07 Failed to report peer bandwidth: API returned non-OK status: 400 Bad Request

and my service works- hurray

and I now have a new acme-dns.json file which looks better

anything else I can do to test it's actually working as expected?

i guess I can't tell from the certificate displayed in the browser:

thanks for all your help - when tested I will post final configs

this is my test setup.. now i will be adding crowdsec

and then I will have to do it all again for my live system

[AstralDestiny]

Best method is to just spin up random resource and see if it uses the certs which it should, Sorry out walking at the moment.

If you're asking about the configs I assume for me to review or so to make sure they are right and not complicated with unrelated?

[cmj01]

Okay thanks testing..
And configs was more just so there are some configs out there at the moment that work. What I have seen is that guides published a few months or years ago no longer work as everything changes fast.

If you're using http validation just know https://crt.sh/ exists alongside other certificate transparency, No you can't opt out but you can use wildcards to more obsecure it's not foolproof but does limit some of the stuff.

regarding this, does this mean I need to remove the http validation option, even if I prefer DNS in the config and it's not using http?

I've done a test with a new random domain in pangolin and cert id doesn't show anything on https://crt.sh/ yet....

Cheers,

Mike