Custom certificate not applied via SNI fallback (certificateType: none) for Compose domains — Error 526 persists even with a valid matching cert in the Certificates store

[Mubashir-teapot]

To Reproduce

ose a different template
Add a title
*
Title
Before opening a new issue, please do a search of existing issues.

If you need help with your own project, you can start a discussion in the Q&A Section.

To Reproduce
*
A detailed, step-by-step description of how to reproduce the issue is required. Please ensure your report includes clear instructions using numbered lists.

If possible, provide a link to a repository or project where the issue can be reproduced.

Markdown Editor
Markdown input: edit mode selected.
Write
Preview

1. Create a application
2. Click X
3. Y will happen

Make sure to:

• Use numbered lists to outline steps clearly.
• Include all relevant commands and configurations.
• Provide a link to a reproducible repository if applicable.
  Current vs. Expected behavior

A clear and concise description of what the bug is, and what you expected to happen.

Markdown Editor
Markdown input: edit mode selected.
Write
Preview
Following the steps from the previous section, I expected A to happen, but I observed B instead
Provide environment information
*
Please provide the following information about your environment.

Operating System:
OS: Ubuntu 20.04
Arch: arm64
Dokploy version: 0.2.2'
VPS Provider: DigitalOcean, Hetzner, Linode, etc.
What applications/services are you tying to deploy?
eg - Database, Nextjs App, laravel, etc.
Which area(s) are affected? (Select all that apply)
*
Are you deploying the applications where Dokploy is installed or on a remote server?
*
Additional context
Any extra information that might help us investigate.

Markdown Editor
Markdown input: edit mode selected.
Write
Preview
I tested on a DigitalOcean VPS with Ubuntu 20.04 and Docker version 20.10.12.
Will you send a PR to fix it?
*
Let us know if you are planning to submit a pull request to address this issue.

Metadata
Assignees
No one assigned
Labels
needs-triage🔍
Type
No type
Projects
No projects
Milestone
No milestone
Please follow this repository's contributing guidelines and security policy.

make me proeprly

a prope msg what we try what happen what what posiblity we try
and everything lhelp me a bit and make a big msg explanation everytihng

os already you know from perious msg
Here's a complete draft for the new issue, ready to paste into each field:

Title:
Custom certificate not applied via SNI fallback (certificateType: none) for Compose domains — Error 526 persists even with a valid matching cert in the Certificates store

To Reproduce:

Deploy a Docker Compose application with multiple services (in our case: 3 Next.js apps + 1 Express API), each assigned its own subdomain under the same root domain via the Domains tab.
Generate a Cloudflare Origin CA certificate covering the exact subdomains in use, copy the certificate and private key.
Go to the dedicated Certificates section in the sidebar → Create Certificate → paste Name / Certificate Data / Private Key → Save. Confirm via SSH that /etc/dokploy/traefik/dynamic/certificates//certificate.yml, chain.crt, and privkey.key are written correctly to disk.
On each service's domain, set Certificate type to none, toggle HTTPS ON. Confirm DNS shows "Behind Cloudflare" (proxied and resolving correctly) for all domains.
Redeploy the Compose application.
Set the Cloudflare zone's SSL/TLS mode to Full (Strict).
Visit any of the domains through Cloudflare → get Error 526 "Invalid SSL Certificate."
Bypass Cloudflare entirely and query the origin server directly with the correct SNI to see what Traefik is actually serving:

nmap --script ssl-cert -p 443
Result: commonName=TRAEFIK DEFAULT CERT — confirms Traefik is not using the uploaded certificate for this domain at all, despite the cert files being present and correctly loaded by the file provider.
Inspect /etc/dokploy/traefik/dynamic/ — only dokploy.yml (dashboard router), middlewares.yml, acme.json, and the certificates/ folder exist. No per-app router/TLS dynamic file exists anywhere, confirming Compose domain routing is generated entirely as Docker labels on the service containers (via Traefik's docker provider) rather than dynamic files — so there's no way to audit the actual applied router/TLS config from the filesystem.
docker inspect --format '{{json .Config.Labels}}' confirms traefik.http.routers..tls=true is present (matching the certificateType === "none" code path), but no certificate ends up being matched via SNI regardless.

Current vs. Expected behavior

Current vs. Expected behavior:
Current: Setting a domain's Certificate type to none — the only documented path for applying a manually-uploaded certificate from the Certificates section to a Compose service's domain — results in Traefik continuing to serve its own self-signed TRAEFIK DEFAULT CERT for that hostname, even though: (a) the uploaded certificate's CN/SAN list exactly matches the domain, (b) the certificate files are confirmed present and well-formed on disk under dynamic/certificates//, and (c) the tls=true label is confirmed present on the container via docker inspect. This results in Cloudflare Full (Strict) rejecting the origin with Error 526, since no valid cert is ever actually presented. The only working fallback is switching Cloudflare to Flexible mode, which removes encryption on the Cloudflare↔origin hop entirely.

Expected: With Certificate type none and a matching certificate present in the Certificates section, Traefik should perform SNI-based matching against its loaded certificate store and present the uploaded certificate during the TLS handshake for that hostname, as described in the docs and by maintainers in the related issue below.

Provide environment information

Environment:

OS: Ubuntu 24.04.3 LTS
Arch: x86_64
Dokploy version: 0.29.8
VPS Provider: Hostinger
Applications: Docker Compose stack — Express/Node.js API, 3x Next.js apps (admin, portal, storefront), PostgreSQL
Which area(s) affected: Docker Compose
Deploying on: Same server where Dokploy is installed

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

Traefik, Docker Compose

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

Same server where Dokploy is installed

Additional context

Additional context:
This is a follow-up to [#], which reported the missing certificate-selector UI in the domain form. PR #4705 addresses that UI gap (adding a way to select a registered certificate), but the testing above shows a second, separate bug underneath it: even using the currently-available none fallback path — which per createDomainLabels() in packages/server/src/utils/docker/domain.ts is supposed to trigger SNI-based matching — the certificate is never actually matched or served by Traefik.

This blocks Cloudflare Full (Strict) mode entirely for Compose services. The only way to get HTTPS working end-to-end right now is Flexible mode, which leaves the Cloudflare↔origin hop unencrypted — a real security gap, not just a UX papercut.

Happy to dig further into the Traefik docker-provider label generation and SNI cert-store matching logic and send a PR once the root cause is confirmed.

Will you send a PR to fix it? Yes

Will you send a PR to fix it?

Yes

[dosubot]

@Mubashir-teapot — this is a well-documented issue report. I dug into the code and prior conversation on #4704 and can confirm what you're seeing is a real bug, not just a UX gap.

Root cause summary:

The certificateType === "none" code path in createDomainLabels() generates only traefik.http.routers.{name}.tls=true [1]. This tells Traefik "enable TLS on this router" but relies entirely on Traefik's implicit SNI matching to select the right certificate from its file-provider-loaded store.

The problem is architectural: Compose service routers are discovered by Traefik's Docker provider, while certificates are loaded by Traefik's file provider [2]. While Traefik should match file-provider certificates to Docker-provider routers via SNI, this cross-provider matching appears to be failing silently — Traefik falls back to TRAEFIK DEFAULT CERT instead.

A few things worth verifying before confirming it's a Traefik-level bug:

1. Exact SAN match — confirm your Cloudflare Origin CA cert's SANs match the Host() rule exactly:

   openssl x509 -in /etc/dokploy/traefik/dynamic/certificates/<id>/chain.crt -text -noout | grep -A1 "Subject Alternative Name"

2. Traefik API raw data — check what Traefik actually sees at /api/rawdata (you may need to temporarily enable the API insecure mode or access via localhost) to confirm both the router and the certificate are loaded.

3. Traefik debug logs — set --log.level=DEBUG on the Traefik container to see if SNI matching is attempted and why it falls back.

For contrast: non-Compose applications use file-based router YAML configs written to /etc/dokploy/traefik/dynamic/{appName}.yml [3], which keeps routers and certificates in the same provider scope. This may explain why SNI matching works for applications but not for Compose.

Potential fix direction for your PR:

Rather than relying on implicit SNI matching across providers, the Compose code path could explicitly add tls.domains labels to the router when a matching certificate exists in the store. Something like:

traefik.http.routers.{name}.tls.domains[0].main={domain}

This would give Traefik an explicit hint for certificate selection. Alternatively, the fix could generate a file-based router config for Compose domains (similar to what applications do) instead of relying solely on Docker labels.

The relevant test file is at apps/dokploy/__test__/compose/domain/labels.test.ts for validating changes. Also note PR #4474 [4] previously fixed a related issue where tls=true wasn't being generated at all for certificateType="none", and PR #4595 [5] fixed certificate discovery by ensuring YAML files are in the correct directory for Traefik's non-recursive file provider.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Mubashir-teapot]

@dosu
Direct origin test (bypassing Cloudflare):

$ openssl s_client -connect <ORIGIN_SERVER_IP>:443 -servername <YOUR_DOMAIN> 2>/dev/null | openssl x509 -noout -issuer -subject
issuer=CN = TRAEFIK DEFAULT CERT
subject=CN = TRAEFIK DEFAULT CERT

Note: Origin server IP and domain are redacted for security reasons.
To reproduce this yourself, get your real server IP (not the Cloudflare
proxy IP) via curl -4 ifconfig.me on the server, then run the openssl
command above directly against that IP with your domain as the SNI
servername. This bypasses Cloudflare entirely and shows what Traefik
is actually serving at the origin.

Certificate on disk covers all 4 subdomains (wildcard + exact match) ✓
certificate.yml present and correctly formatted ✓
tls=true label confirmed on containers via docker inspect ✓
acme.json has no entry for these domains (Let's Encrypt not involved) ✓

Conclusion: Despite the Cloudflare Origin CA certificate being correctly
uploaded, present on disk, and loaded by Traefik's file provider — the
SNI matching across providers completely fails. Traefik always falls back
to TRAEFIK DEFAULT CERT at the origin. This causes Cloudflare Full (Strict)
to reject the handshake with Error 526, since the origin never presents
a valid trusted certificate.

[dosubot]

@Mubashir-teapot — I found the root cause, and it's not a cross-provider SNI matching bug. It's simpler and more fundamental:

Traefik's file provider is non-recursive. It only watches the top-level /etc/dokploy/traefik/dynamic/ directory. Your certificate.yml is nested at:

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

That's two levels deep — Traefik never discovers it [1]. The cert files are on disk and the YAML is correctly formatted, but Traefik literally never reads the file, so it has no certificate to match via SNI. That's why it always falls back to TRAEFIK DEFAULT CERT.

The fix: PR #4595 [1] directly addresses this by relocating certificate registration YAML files to the top level (/etc/dokploy/traefik/dynamic/{certificatePath}-certificate.yml) while keeping the PEM files in their subdirectories. This PR is currently open (submitted June 9, 2026).

Immediate workaround: You can manually copy or symlink your certificate.yml to the top-level dynamic directory:

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

Since watch: true is enabled [2], Traefik should pick it up immediately and start matching it via SNI to your domains. This should resolve the 526 without any code changes.

Your PR effort might be best directed at helping get #4595 merged or rebased if needed, since it already solves the underlying discovery problem.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Mubashir-teapot]

Update — Workaround confirmed working:
The manual workaround suggested by @dosu worked perfectly. Copying the certificate.yml from the nested subdirectory to the top-level dynamic directory immediately fixed the issue — Traefik started serving the correct Cloudflare Origin CA certificate instead of TRAEFIK DEFAULT CERT, and Cloudflare Full (Strict) mode is now working without Error 526.
Verified via direct origin test (bypassing Cloudflare):
Before workaround:
issuer=CN = TRAEFIK DEFAULT CERT
subject=CN = TRAEFIK DEFAULT CERT

After workaround:
issuer=C = US, O = "CloudFlare, Inc.", OU = CloudFlare Origin SSL Certificate Authority
subject=O = "CloudFlare, Inc.", OU = CloudFlare Origin CA, CN = CloudFlare Origin Certificate
The root cause is confirmed: Traefik's file provider is non-recursive and never discovers certificate.yml files nested inside subdirectories under /etc/dokploy/traefik/dynamic/certificates//. The cert files are correctly written to disk by Dokploy, but Traefik never reads them, so SNI matching never happens and it always falls back to TRAEFIK DEFAULT CERT.
This will silently break HTTPS for anyone using manually uploaded certificates with Cloudflare Full (Strict) mode. The fix needs to land in the codebase so certificate YML files are written directly to the top-level dynamic directory — PR #4595 already addresses this and should be prioritized for merge.

[dosubot]

@Mubashir-teapot — glad to hear the workaround resolved it cleanly. Your verification with the direct origin openssl test before/after is exactly the kind of confirmation that makes this actionable.

To summarize for anyone else hitting this: the issue is that Dokploy writes certificate.yml to /etc/dokploy/traefik/dynamic/certificates/<id>/certificate.yml, but Traefik's file provider only watches the top-level /etc/dokploy/traefik/dynamic/ directory non-recursively — so it never discovers the nested file, never loads the certificate, and always falls back to its self-signed default cert.

Quick workaround until the fix is merged:

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

PR #4595 [1] solves this properly by relocating the registration YAML to the top level while keeping PEM files in their subdirectories. Agreed it should be prioritized — this silently breaks any manually uploaded certificate setup under strict TLS modes.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Mubashir-teapot]

Here's your comment to paste:

Resolved — Root cause confirmed and workaround available:
After deep investigation, the root cause of this issue has been identified. It is not a cross-provider SNI matching bug — it is simpler and more fundamental.
Root cause:

Traefik's file provider is non-recursive. It only watches the top-level /etc/dokploy/traefik/dynamic/ directory. Dokploy writes certificate.yml into a nested subdirectory:
/etc/dokploy/traefik/dynamic/certificates//certificate.yml
Traefik never discovers this file, so it has no certificate to match via SNI and always falls back to TRAEFIK DEFAULT CERT. This silently breaks HTTPS for anyone using manually uploaded certificates with Cloudflare Full (Strict) mode, causing Error 526.
Immediate workaround (confirmed working):
bashsudo cp /etc/dokploy/traefik/dynamic/certificates//certificate.yml
/etc/dokploy/traefik/dynamic/-certificate.yml
Traefik picks it up instantly since watch: true is enabled. No restart needed.
Verified via direct origin test bypassing Cloudflare:
Before: issuer=CN = TRAEFIK DEFAULT CERT
After: issuer=C = US, O = "CloudFlare, Inc.", OU = CloudFlare Origin SSL Certificate Authority
Permanent fix:

The path where Dokploy writes certificate.yml needs to be changed from the nested subdirectory to the top-level dynamic directory. I am working on a PR to fix this properly so it works automatically for everyone without any manual steps.