Custom certificate created in Certificates section has no way to be applied to a Compose service's domain #4704

Activity

1. Mubashir-teapot

   added

   needs-triage🔍

   on Jun 28, 2026
2. dosubot

   added

   bugSomething isn't workingSomething isn't working

   on Jun 28, 2026
3. dosubot commented on Jun 28, 2026

   

   dosubotBot

   on Jun 28, 2026 – with DosuBot

   More actions

   Hi @Mubashir-teapot! I'm Dosu and I'm helping the Dokploy team.

   You've identified a real architectural gap. Here's what's happening under the hood:

   The "Certificates" section and "Custom Certificate Resolver" field serve different purposes:

   • The Certificates section creates physical certificate files at /etc/dokploy/traefik/dynamic/certificates/{id}/ with a certificate.yml that Traefik auto-loads via its file provider [1]. These are TLS certificates that Traefik knows about but they're matched to domains via SNI — Traefik will use them automatically if the certificate's CN/SAN matches the requested domain and the router has tls: {} enabled without a specific certResolver.

   • The "Custom Certificate Resolver" field on a domain expects the name of a Traefik certificatesResolver (e.g. "letsencrypt") — not raw cert data, and not the name of a certificate from the Certificates section [2] [3]. For Compose services, this gets injected as a Docker label: traefik.http.routers.{name}.tls.certresolver={value} [3].

   Why your setup fails with Error 526:

   When you set certificate type to "custom" and paste cert/key content into the "Custom Certificate Resolver" text field, that value gets used as a literal resolver name in Traefik's config. Since no such resolver exists, Traefik can't obtain/present a certificate, and Cloudflare's Full (Strict) mode rejects the connection.

   The workaround for now:

   If you've created a certificate in the Certificates section whose CN/SAN matches your domain, you should be able to set the certificate type to "none" on the domain. This sets tls: {} without a certResolver, which lets Traefik fall back to SNI-based certificate selection from its loaded certificate store — i.e., it should pick up the certificate you created in the Certificates section. This is worth testing.

   On the UX gap:

   This was also raised in issue #4610, which proposed replacing the free-text input with a dropdown of registered certificates. That issue was closed without a fix. Your description is clearer about the actual problem — the docs say "select your newly created certificate" but no such selector exists in the domain form for Compose services. A PR adding a dropdown (or at minimum, proper documentation of the expected format) would be a welcome improvement.

   Would you like me to look into the specific code paths for Compose domain label generation to help guide your PR?

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
4. Mubashir-teapot commented on Jun 29, 2026

   

   Mubashir-teapot

   on Jun 29, 2026

   Author

   More actions

   Tested the "None" certificate type workaround it did not resolve the issue. Still getting Error 526 from Cloudflare in Full (Strict) mode.

   Confirmed the certificate itself is loading correctly: its files (certificate.yml, chain.crt, privkey.key) are present under /etc/dokploy/traefik/dynamic/certificates//, and Traefik's file provider does pick those up. The gap is specifically on the domain/router side.

   Separately, I tried to inspect the actual router config Dokploy generates for my Compose service's domains to debug this myself, but couldn't find it anywhere under /etc/dokploy/traefik/dynamic/ — that directory only contains acme.json, dokploy.yml (which is just Dokploy's own dashboard router), middlewares.yml, and the certificates folder. No per-app routing file exists there for a Compose service's domains.

   If Dokploy generates these routes as Docker labels on the service containers (via the docker provider in traefik.yml) rather than as dynamic files, that's fine, but it means there's currently no way for a user to see or audit the actual router/TLS config being applied to their domain through the filesystem — only by manually docker inspecting each container's labels. Could someone confirm whether that's the intended mechanism for Compose services? If so, it'd be worth documenting, since right now there's no visibility into what Dokploy is actually telling Traefik for a given domain, which makes debugging issues like this one (and #4610) much harder than it needs to be.

   This also isn't just a UX papercut it's a real security gap. Without a working path to apply a custom certificate, Full (Strict) Cloudflare↔origin encryption isn't achievable through the UI at all, forcing a fallback to Flexible mode (unencrypted Cloudflare↔origin hop) as the only way to get HTTPS working end to end.

   On the offer to dig into this myself: I've been reviewing how my own stack manages Docker/Traefik config while debugging this, so I'm comfortable working through the actual mechanism if pointed at the relevant source — happy to review the real Compose domain/label-generation code and send a PR if that's useful. I did try manually editing Traefik's config directly on my server to work around this, but that caused its own issues, so I've held off going further down that path solo. Rather not fight this blind — if someone can point me at the right files, I'll take a real pass at fixing it; otherwise happy to hand this off and let the team take it from here.
5. dosubot commented on Jun 29, 2026

   

   dosubotBot

   on Jun 29, 2026 – with DosuBot

   More actions

   @Mubashir-teapot — you're correct: Compose service routes are generated entirely as Docker labels on the service containers, not as dynamic YAML files. The only file-based dynamic configs are dokploy.yml (dashboard), middlewares.yml, acme.json, and the certificates folder. For Compose services, Traefik discovers routing via its Docker provider, so docker inspect is indeed the only way to audit the applied config. That's the intended mechanism, though I agree it lacks visibility.

   Here are the relevant source files for a PR:

   Primary file: packages/server/src/utils/docker/domain.ts

   • createDomainLabels() (lines 255–348) — generates all Traefik labels for a domain, including TLS handling [1]
   • addDomainToCompose() (lines 134–237) — injects those labels into the compose spec [2]
   • writeDomainsToCompose() (lines 109–133) — encodes the modified compose file and returns the deployment command [3]

   Integration point: packages/server/src/utils/builders/compose.ts at line 26 calls writeDomainsToCompose() [4].

   Regarding certificateType === "none": The code at lines 340–344 does set traefik.http.routers.{name}.tls=true when HTTPS is enabled [5]:

   } else if (certificateType === "none" && https) {
       labels.push(`traefik.http.routers.${routerName}.tls=true`);
   }

   This should allow Traefik to use SNI-based matching against its loaded certificate store. If you're still getting 526, it's worth verifying:

   1. The CN or SAN on your Cloudflare Origin CA cert matches the domain exactly (wildcard or FQDN)
   2. Traefik is actually loading the cert (check docker logs on the Traefik container for TLS-related messages or hit the Traefik API at /api/rawdata to see loaded certificates and router configs)

   If the cert is loaded and SNI matching just isn't working, the fix in your PR might need to add explicit tls.domains or tls.options labels pointing to the certificate, or introduce a proper dropdown that maps to the certificate's path directly — rather than relying on Traefik's implicit SNI matching.

   There are also tests at apps/dokploy/__test__/compose/domain/labels.test.ts if you want to validate behavior changes.

   To reply, just mention @dosu.

   ---

   Docs are dead. Just use Dosu.

   
6. Siumauricio commented on Jun 29, 2026

   

   Siumauricio

   on Jun 29, 2026

   Contributor

   More actions

   Hey, I added some suggestions on the UI, If you want to use a cloudflare certificate you can follow this guide https://docs.dokploy.com/docs/core/domains/cloudflare
7. Siumauricio

   closed this as completedin #4705on Jun 29, 2026
8. Siumauricio

   removed

   needs-triage🔍

   on Jun 29, 2026
9. Mubashir-teapot commented on Jun 29, 2026

   

   Mubashir-teapot

   on Jun 29, 2026

   Author

   More actions

   Thanks both — tried the Cloudflare guide approach again (Certificate type none on the domain, matching cert in the Certificates section) and confirmed via direct SNI check against the server (bypassing Cloudflare entirely) that Traefik is still presenting TRAEFIK DEFAULT CERT, not the uploaded one:

   $ nmap --script ssl-cert -p 443
   | ssl-cert: Subject: commonName=TRAEFIK DEFAULT CERT
   | Subject Alternative Name: DNS:.traefik.default
   So the SNI-based fallback @dosu described (tls=true with no certResolver → Traefik should match against its loaded cert store) isn't kicking in for me, even though the cert files are confirmed present and well-formed on disk (certificate.yml, chain.crt, privkey.key under dynamic/certificates//). Still getting 526 from Cloudflare in Full (Strict).

   @Siumauricio I saw #4705 — is that merged into a build I can pull and test, or still pending? Want to confirm whether this is purely the missing-selector UX gap your PR addresses, or a separate bug in the SNI fallback matching itself. If the fallback is genuinely not matching despite a valid CN/SAN, that's a second issue beyond just "no UI to pick a cert" — happy to dig into createDomainLabels()/addDomainToCompose() and the Traefik docker-provider side to confirm which one it is, and send a PR once I know which.
10. dosubot commented on Jun 29, 2026

    

    dosubotBot

    on Jun 29, 2026 – with DosuBot

    More actions

    @Mubashir-teapot — I dug into this further and I think you're right that there's a real bug here beyond just the missing UI selector. Here's what I found:

    PR #4705 adds help text to the domain form confirming the expected behavior: when "None" is selected, Traefik should automatically match a loaded certificate via SNI [1]. It's a docs/UX improvement, not a fix for the SNI matching itself.

    Why SNI matching may be failing:

    The certificate.yml generated by Dokploy contains only file paths — no domain/SAN hints [2]:

    tls:
      certificates:
        - certFile: /path/to/chain.crt
          keyFile: /path/to/privkey.key

    Traefik must parse the actual .crt file to extract CN/SAN for matching. For this to work, the certificate's CN/SAN must exactly match the domain in the router's Host() rule. A few things to check:

    1. Verify your cert's CN/SAN:

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

    2. Verify the exact Host() rule on the container:

       docker inspect <your-compose-container> | grep "traefik.http.routers"

    3. Compare them exactly — Compose services don't normalize domains (no lowercase conversion), so if there's any case mismatch between the Host() rule and the cert's SAN, SNI matching will silently fail and Traefik falls back to its default cert [3].

    4. Cloudflare Origin CA wildcards — if your cert is *.example.com but the Host() rule is example.com (bare domain, no subdomain), that won't match either.

    Also worth checking Traefik's debug logs (--log.level=DEBUG) — it should log which certificates it's loading from the file provider and any SNI matching attempts.

    If the CN/SAN and Host() rule match correctly and it still falls back to the default cert, that would confirm a bug in how Traefik processes file-provider certificates for Docker-provider routers — which would be a separate issue from what #4705 addresses.

    To reply, just mention @dosu.

    ---

    Share context across your team and agents. Try Dosu.