Cloudflare Origin CA: "Certificate: None" does not stop Let's Encrypt for the domain (websecure entrypoint default)

[onlyilkr]

To Reproduce

1. Deploy an application and create a domain with Certificate: Let's Encrypt. Wait until Traefik has issued the certificate, so that an entry for the hostname exists in /etc/dokploy/traefik/dynamic/acme.json.
2. In the Cloudflare dashboard, go to SSL/TLS > Origin Server > Create Certificate and create an Origin CA certificate covering the domain, for example example.com and *.example.com, valid for 15 years.
3. In Dokploy, go to Certificates > Add Certificate and paste the Origin Certificate and Private Key, following Using Cloudflare's Origin CA.
4. Edit the existing domain and change the Certificate field from Let's Encrypt to None.
5. In Cloudflare, set the SSL/TLS encryption mode to Full (Strict).
6. On the server, check which certificate Traefik actually serves for that hostname:

echo | openssl s_client -connect 127.0.0.1:443 -servername app.example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

Current vs. Expected behavior

Current behavior

Traefik keeps serving the old Let's Encrypt certificate, not the Origin CA one:

issuer=C = US, O = Let's Encrypt, CN = R12
notAfter=Jul 28 14:45:05 2026 GMT

Traefik also keeps attempting to renew it. Once that certificate expires, Cloudflare returns Error 526 (Invalid SSL certificate) in Full (Strict) mode, even though the Origin CA certificate was uploaded correctly and the domain is set to Certificate: None. Nothing in the UI indicates which certificate is in use, so the setup looks correct while the site is down.

Expected behavior

Setting Certificate: None should stop Let's Encrypt for that domain and let the uploaded Origin CA certificate take over.

Workaround

Removing the hostname's entry from acme.json and restarting Traefik makes the Origin CA certificate take over immediately. On my instance all 13 hostnames switched to CloudFlare Origin SSL Certificate Authority (valid until 2041) with no other change.

Provide environment information

Operating System:
  OS: Ubuntu 24.04.4 LTS
  Arch: x86_64
  Kernel: 6.8.0-136-generic
Dokploy version: v0.29.13
Traefik version: v3.6.7
Docker version: 29.4.1 (Swarm active)
VPS Provider: Hetzner
What applications/services are you trying to deploy?
  Next.js apps, Node APIs, PostgreSQL, MinIO, Redis, Uptime Kuma

Which area(s) are affected? (Select all that apply)

Traefik, Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

Two separate mechanisms seem to be involved.

1. Certificate: None only clears the router-level resolver.

The websecure entrypoint carries an instance-wide default that applies to every router which does not define its own TLS block, so the router still falls back to the ACME resolver.

packages/server/src/setup/traefik-setup.ts L286-L298:

websecure: {
  address: `:${TRAEFIK_SSL_PORT}`,
  http3: { advertisedPort: TRAEFIK_HTTP3_PORT },
  ...(process.env.NODE_ENV === "production" && {
    http: { tls: { certResolver: "letsencrypt" } },
  }),
},

The same block exists unconditionally in getDefaultServerTraefikConfig (L344-L354), while Certificate: None only skips the per-router assignment in packages/server/src/utils/traefik/domain.ts L213-L217.

2. Certificate selection favours the old certificate.

Traefik picks the more specific match, so a Let's Encrypt certificate with DNS:app.example.com wins over an Origin CA certificate with DNS:*.example.com. I confirmed this on my instance: hostnames that only the wildcard could match were already served the Origin CA certificate, while hostnames with an exact-match Let's Encrypt entry kept the expired one.

What I could not verify

My ACME challenges were being intercepted by Cloudflare Access, so Traefik could never obtain a new Let's Encrypt certificate. I therefore could not observe whether, on an instance where ACME succeeds, the entrypoint default causes a fresh certificate to be issued for a Certificate: None domain and shadow the Origin CA one. That last link is inferred from Traefik's documented entrypoint-default semantics, not measured. It would be good if someone could confirm it.

Possible directions

• Do not set certResolver at the entrypoint level, and rely on the per-router value Dokploy already writes for Let's Encrypt domains. Mixed setups keep working, since those routers carry their own tls.certResolver.
• Or, when a domain is switched away from Let's Encrypt, drop its entry from acme.json.
• At minimum, document the migration path. I have opened a docs PR for this: docs: document migrating an existing domain to Cloudflare Origin CA website#172

Related to #1839, which asked for Origin CA support before the Certificates feature existed.

Will you send a PR to fix it?

Maybe, need help

[linear-code]

DOK-602

[dosubot]

Hi @onlyilkr! I'm Dosu and I'm helping the Dokploy team.

Great bug report — your analysis is spot on. I can confirm both root causes from the code.

1. Entrypoint-level certResolver fallback: The websecure entrypoint unconditionally sets certResolver: "letsencrypt" as a default in production [1]. When certificateType is "none", the file-config path sets routerConfig.tls = undefined [2], and the Docker-label path emits only tls=true without a resolver [3]. Neither is sufficient to override the entrypoint default — Traefik falls back to the ACME resolver, exactly as you described.

2. No acme.json cleanup: There is no code anywhere in Dokploy that removes entries from acme.json when a domain switches away from Let's Encrypt [4]. Old certificates persist and win over wildcard Origin CA certs due to Traefik's more-specific-match-first rule.

3. Related issue — certificate file discovery: It's also worth noting that Traefik's file provider is non-recursive, and Dokploy currently writes certificate.yml to a nested subdirectory (/etc/dokploy/traefik/dynamic/certificates/<id>/certificate.yml) that Traefik never discovers [5]. This was confirmed and worked around in #4707 [6]. If you haven't already, you may need to copy that file to the top level as well:

cp /etc/dokploy/traefik/dynamic/certificates/<id>/certificate.yml \
   /etc/dokploy/traefik/dynamic/<id>-certificate.yml

Your suggested fix directions both make sense. Removing the entrypoint-level certResolver and relying solely on per-router assignment (which Dokploy already writes for letsencrypt domains) seems like the cleaner approach — it avoids surprising fallback behavior for any certificate mode. The acme.json cleanup would be a nice addition on top of that.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[onlyilkr]

Thanks @dosu — points 1 and 2 match what I found on my instance. Point 3 needs a correction though, because the mechanism is subtler than "Traefik never discovers nested files", and the distinction changes what the right fix is.

Traefik's file provider loads nested files; only the watcher is non-recursive.

From the v3.6 source (pkg/provider/file/file.go):

• loadFileConfigFromDirectory recurses into subdirectories:

  if item.IsDir() {
    configuration, err = p.loadFileConfigFromDirectory(logger.WithContext(ctx),
      filepath.Join(directory, item.Name()), configuration)

• but the fsnotify watcher is only added on the top-level entries, so changes inside subdirectories don't trigger a reload on their own.

So nested certificate.yml files are read — at startup, and on any reload triggered by a change to a top-level file (each reload re-reads the whole tree recursively). What doesn't work is hot-reload for a file that appears two levels deep while nothing at the top level changes.

Empirical confirmation from my instance (Dokploy v0.29.13, Traefik v3.6.7): the certificate YAMLs are exactly where Dokploy wrote them, two levels deep, and nothing was ever copied to the top level:

$ grep -rl certFile /etc/dokploy/traefik/dynamic/
/etc/dokploy/traefik/dynamic/certificates/certificate-parse-haptic-port-co67ny/certificate.yml
/etc/dokploy/traefik/dynamic/certificates/certificate-back-up-virtual-port-wff9rg/certificate.yml
/etc/dokploy/traefik/dynamic/certificates/certificate-program-virtual-application-dwo46q/certificate.yml

$ ls /etc/dokploy/traefik/dynamic/ | grep -i certificate
certificates

The ACME store is empty (Certificates: [], only the Account object remains), yet all 13 hostnames serve the Origin CA certificate:

$ echo | openssl s_client -connect 127.0.0.1:443 -servername app.example.com 2>/dev/null \
    | openssl x509 -noout -issuer -enddate
issuer=C = US, O = "CloudFlare, Inc.", OU = CloudFlare Origin SSL Certificate Authority, ...
notAfter=Jul 25 23:14:00 2041 GMT

With an empty ACME store and no top-level certificate config, the nested files are the only possible source, so they were loaded. In fact they were picked up before I ever restarted Traefik — because changing the domains' certificate settings in the UI rewrote top-level router YAMLs at the same time, and each of those writes triggered a full recursive reload.

Why this matters for #4707 and PR #4595: the load/watch distinction explains that report more precisely than "non-recursive file provider":

• For Applications, domain changes write top-level YAMLs, so a cert upload is almost always followed by a reload trigger — nested certs get loaded, things work.
• For Compose, domains live in Docker labels. Uploading a certificate writes only the nested files — no top-level change, no reload, and Traefik serves TRAEFIK DEFAULT CERT until something else (or a restart) forces a reload. That matches the reporter's symptom exactly. (Hypothesis on my part — I run Applications, not Compose, so someone with a Compose setup should confirm.)

Practical consequence: the cp-to-top-level workaround "works" because creating a top-level file is itself a reload trigger — but a plain docker restart dokploy-traefik achieves the same. And #4595 (writing the registration YAML at the top level) is still a reasonable fix, just for the watch limitation, not because nested files are invisible.

On the fix direction for this issue, agreed with your assessment — dropping the entrypoint-level certResolver and relying on the per-router value Dokploy already writes looks like the cleaner change, with acme.json cleanup on provider switch as a follow-up. I've opened a docs PR covering the manual migration path in the meantime: Dokploy/website#172

[dosubot]

@onlyilkr — excellent correction, and thanks for tracing it through the Traefik source. You're right that my earlier characterization was too blunt. The distinction between recursive loading (which works fine for nested files) and the non-recursive fsnotify watcher (which only triggers on top-level changes) is important, and it cleanly explains the difference between the Application and Compose experiences:

• Applications: domain config changes write top-level YAMLs → watcher fires → full recursive reload picks up nested cert files ✓
• Compose: domains are Docker labels, so uploading a cert only writes nested files → no top-level change → no watcher event → TRAEFIK DEFAULT CERT until a restart or unrelated top-level write triggers a reload

Your empirical evidence is definitive — 13 hostnames serving Origin CA from nested-only cert files, no top-level copies, empty ACME store. That's as clean a confirmation as it gets.

Agreed on the fix path: drop the entrypoint-level certResolver, rely on per-router assignment, and treat acme.json cleanup as a follow-up. Thanks for opening the docs PR (Dokploy/website#172) to cover the manual migration in the meantime.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[hanzalaops]

Hi @onlyilkr , great write-up, very clear and easy to follow.

I checked the code myself and both points are correct:

1. websecure entrypoint always sets certResolver: "letsencrypt" as default (traefik-setup.ts, around line 291). When a domain is set to Certificate: None, the router just skips setting its own resolver (domain.ts, around line 218: routerConfig.tls = undefined). It does not turn off the default. So Traefik still falls back to Let's Encrypt for that domain.

2. There is no code anywhere that removes old entries from acme.json when a domain is switched away from Let's Encrypt. So the old certificate stays and can still win.

I'd like to help fix this, if that's okay with you. My plan:

• Remove the hardcoded certResolver from the websecure entrypoint default.
• Keep using the per-router tls.certResolver that Dokploy already writes for letsencrypt domains, so normal setups keep working the same way.
• Clean up the matching acme.json entry when a domain's certificate type is changed away from letsencrypt, as a follow-up.

Let me know if you're already working on this or if you'd like to pair on it.

Happy to send a PR once we agree on the approach.

[onlyilkr]

Thanks @hanzalaops, good to see an independent read land on the same two points. I'm already well into this one, so I'll carry it through and have a PR up shortly.

First, a correction to my own report: the direction I suggested in "Possible directions" turns out to be unnecessary. Traefik applies an entrypoint's TLS default only to routers whose TLS is nil (pkg/server/aggregator.go, applyModel, on the v3.6.7 Dokploy pins):

if cp.TLS == nil {
    cp.TLS = m.TLS
}

So the problem isn't that websecure carries a certResolver default, it's that certificateType: "none" writes routerConfig.tls = undefined and never overrides it. Writing {} instead fixes it with the entrypoint untouched, so no traefik.yml migration and no risk of tls: ending up null, which would disable TLS and turn 526 into 525 everywhere. forward-auth.ts already does exactly this for the same case, so it's really a consistency fix. Same one line change in the Docker label path, which also closes a smaller gap where certificateType: "custom" with an empty customCertResolver falls through to nil as well.

Two more pieces beyond that.

The acme.json cleanup from my original report: when a domain moves away from Let's Encrypt, drop its entry, skipping the removal if another domain still uses that hostname with Let's Encrypt. Traefik reads acme.json once at startup and serves from memory after that, so it only takes effect on reload. I'd rather not reload silently on a domain save since that briefly drops every site on the server, so my plan is to do the cleanup and report that a reload is needed, leaving the existing Reload Traefik action to the user. That's more a product call than a technical one, so say the word if you'd prefer it automatic.

A one-shot reconciliation at startup, which is new and the part I most want your read on. Without it the fix only reaches new domains: existing installs keep the router YAML generated when the domain was saved, and manageDomain runs on domain create and update but not on deploy, so users would have to re-save every affected domain by hand. What I have in mind is narrow. It only looks at domains whose certificateType isn't letsencrypt, only reads those applications' configs, and only calls manageDomain where the websecure router is actually missing its TLS key. Idempotent after the first pass, preserves manual edits since manageDomain replaces only its own router and service keys, and failures are isolated per application so an unreachable remote server can't block startup. If you'd rather nothing touched configs at boot, I'm happy to drop it and document the re-save instead.

@Siumauricio, I'll start on the PR now, with unit tests for all three certificate types on both paths plus the acme.json guard, tested locally per the contributing guidelines. CONTRIBUTING asks for significant changes to be aligned in an issue first, so I've put the approach here rather than just sending code. Happy to split it up if you'd prefer the cleanup and the reconciliation kept separate from the router fix, which stands on its own.

Docs PR for the manual workaround in the meantime: Dokploy/website#172.