wildcard cert renewal failed on route53 propagation timeout

Not specified by the original author.

TL;DR

For "unable to obtain certificate": set 1.1.1.1:53/8.8.8.8:53 when the container's DNS is unreliable. - Traefik supports only one DNS provider per resolver. Check the Traefik dashboard / API for the resolver name. Set explicit resolvers (1.1.1.1:53) if the container's DNS is filtered.

unable to obtain certificate

When to use

You are seeing this: There is no HTTP-01 or TLS-ALPN-01 path to a wildcard cert. Use this skill when you run into "Fix Traefik wildcard certificate failures: ACME DNS-01 in Docker".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.1.1.1, 8.8.8.8. If you are on something much newer or older, the details may have shifted.

Applies to: Traefik v3 in Docker/Docker Compose, Let's Encrypt via ACME, DNS-01 challenge through lego DNS providers (Cloudflare, Route53, etc.), wildcard (*.example.com) certificates.

The problem this solves

You run Traefik in Docker, you want a wildcard cert (*.example.com) from Let's Encrypt, and you keep hitting one of these:

• unable to obtain certificate in the Traefik logs and no acme.json entry
• The TXT record appears in your DNS but Let's Encrypt says the challenge failed
• Config that "looked right" does nothing because you put it in the wrong config file
• You burned through Let's Encrypt rate limits while debugging and now every attempt fails for a different reason

Wildcards only work through the DNS-01 challenge. There is no HTTP-01 or TLS-ALPN-01 path to a wildcard cert.

1. The one decision that bites everyone: static vs dynamic config

Traefik has two separate configurations, and certificatesResolvers lives in exactly one of them:

• Static config (loaded once at startup; changing it requires a Traefik restart): entrypoints, providers, and certificatesResolvers. This is traefik.yml, CLI flags (--certificatesresolvers.NAME...), or env vars.
• Dynamic config (reloaded without restart): routers, services, middlewares. Docker labels, file provider, etc.

Consequences:

• The resolver definition (provider, email, storage, dnsChallenge) goes in static config only. Putting certificatesResolvers in a dynamic file (e.g. dynamic.yml or a compose label) is silently ignored, nothing is requested, nothing errors loudly.
• The resolver reference goes in dynamic config: traefik.http.routers.myapp.tls.certresolver=DNS_RESOLVER_NAME on the router. The name must match the key under certificatesResolvers in static config.

2. Which challenge to use

Use DNS-01 when you need wildcards, when port 80/443 is blocked or proxied (e.g. behind Cloudflare), or when Traefik isn't directly internet-facing.

3. Static config: the resolver (traefik.yml)

This is the canonical v3 shape. Note the propagation block, the old flat keys delayBeforeCheck / disablePropagationCheck are deprecated in v3 and must not be used.

# traefik.yml — STATIC config, loaded once at startup
entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

certificatesResolvers:
  dns-resolver:                     # <- the name routers reference as tls.certResolver
    acme:
      email: "ACME_CONTACT_EMAIL"
      storage: "/letsencrypt/acme.json"   # path INSIDE the container; must be writable + persisted
      caServer: "https://acme-v02.api.letsencrypt.org/directory"
      dnsChallenge:
        provider: cloudflare              # lego provider code, e.g. cloudflare, route53, digitalocean
        resolvers:
          - "1.1.1.1:53"
          - "8.8.8.8:53"
        propagation:
          delayBeforeChecks: 30s          # wait before verifying TXT propagation (Go duration string, not an integer)
          # disableChecks: true           # only if the container cannot reach external DNS at all; not recommended

TOML equivalent for the resolver block:

[certificatesResolvers.dns-resolver.acme]
  email = "ACME_CONTACT_EMAIL"
  storage = "/letsencrypt/acme.json"
  caServer = "https://acme-v02.api.letsencrypt.org/directory"
  [certificatesResolvers.dns-resolver.acme.dnsChallenge]
    provider = "cloudflare"
    resolvers = ["1.1.1.1:53", "8.8.8.8:53"]
    [certificatesResolvers.dns-resolver.acme.dnsChallenge.propagation]
      delayBeforeChecks = "30s"

Key details:

• storage is required. Create the file before first start and give it owner-only permissions, then mount it as a file or use a named volume: touch acme.json && chmod 600 acme.json. An unreadable or unwritable storage path is a common silent failure.
• email is required for ACME registration.
• dnsChallenge.provider is the lego provider code, lowercase, e.g. cloudflare, route53. Full list: lego DNS providers documentation.
• delayBeforeChecks is a Go duration string (30s, 2m), default 0s. Traefik verifies the TXT record itself before telling Let's Encrypt; this delays that check. Useful when your network blocks the container's outbound DNS queries, or when your provider's API is slow to propagate.
• resolvers overrides which DNS servers lego uses to check propagation (default: system resolvers). Set 1.1.1.1:53/8.8.8.8:53 when the container's DNS is unreliable.
• Traefik supports only one DNS provider per resolver. For multiple providers/accounts, CNAME _acme-challenge.example.com to a domain handled by the configured provider (CNAME following is on by default; LEGO_DISABLE_CNAME_SUPPORT=true turns it off).

4. Docker Compose: credentials live on the Traefik container

Lego reads provider credentials only from environment variables (a _FILE suffix reads the value from a file instead). These go on the traefik service, not your app services.

services:
  traefik:
    image: traefik:v3
    command:
      - --configFile=/etc/traefik/traefik.yml
      - --log.level=DEBUG              # drop to INFO once issuance works
    environment:
      # Cloudflare, preferred: set CF_DNS_API_TOKEN to an API token
      # with Zone:Read + DNS:Edit on every zone involved.
      # (legacy alternative: CF_API_EMAIL + CF_API_KEY — grants full account access, avoid)
      # Aliases also work: CLOUDFLARE_DNS_API_TOKEN
    volumes:
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
      - ./acme.json:/letsencrypt/acme.json
    ports:
      - "80:80"
      - "443:443"

Provider env vars (verified against lego docs):

Provider-side propagation tunables (also env vars): CLOUDFLARE_PROPAGATION_TIMEOUT (default 120s), CLOUDFLARE_TTL (default 120s), AWS_PROPAGATION_TIMEOUT (default 120s), AWS_TTL (default 10s).

5. Dynamic config: attach the resolver to a router

Labels on your app service (dynamic config):

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.myapp.rule=Host(`app.example.com`)"
  - "traefik.http.routers.myapp.entrypoints=websecure"
  - "traefik.http.routers.myapp.tls=true"
  - "traefik.http.routers.myapp.tls.certresolver=dns-resolver"
  - "traefik.http.routers.myapp.tls.domains[0].main=example.com"
  - "traefik.http.routers.myapp.tls.domains[0].sans=*.example.com"

Wildcard + apex note: a cert for *.example.com does not cover the bare example.com. Request both by setting main: example.com with sans: *.example.com, this triggers two DNS-01 challenges, and both write to the same _acme-challenge TXT name. The lego provider table notes which providers handle this; if your provider's TXT TTL exceeds the challenge timeout, the second challenge can fail, raise propagation timeouts or lower the TXT TTL.

6. Debugging unable to obtain certificate

Work this list in order. Do every step against the staging CA first (caServer: https://acme-staging-v02.api.letsencrypt.org/directory) so failed attempts don't count against production rate limits.

1. Read the actual error: docker logs traefik with --log.level=DEBUG. The log line names the failing piece (provider auth, propagation, ACME order). Don't guess, the provider name and HTTP status are usually in the line.
2. Is the resolver even loaded? Check the Traefik dashboard / API for the resolver name. If it's missing, the certificatesResolvers block is in the wrong config source (dynamic file instead of static) or has a YAML/TOML syntax error that prevented startup parsing.
3. Provider auth: 401/403 from the DNS API means wrong or insufficient credentials. Cloudflare: token needs Zone:Read + DNS:Edit on every zone involved; using the Global API Key when you meant a token (or vice versa) fails. Route53: IAM policy missing one of the four actions fails at TXT creation.
4. TXT propagation: if the log shows the TXT record was created but validation timed out, raise propagation.delayBeforeChecks (e.g. 60s) and/or the provider's *_PROPAGATION_TIMEOUT. Set explicit resolvers (1.1.1.1:53) if the container's DNS is filtered.
5. Wrong provider code: dnsChallenge.provider must be the exact lego code (cloudflare, not Cloudflare). A wrong code fails at startup with an unknown-provider error.
6. acme.json problems: file must exist and be writable by the Traefik process; a corrupted file (e.g. from an interrupted write) can be renamed aside and re-issued, but only after the underlying error is fixed, or you'll hit rate limits re-issuing.
7. Rate limits: Let's Encrypt caps failed validations per hostname per hour and certificates per domain per week. If everything "looks fixed" but issuance still fails, you may be rate-limited, switch to staging and wait it out.
8. Only one resolver challenge per router: don't set httpChallenge and dnsChallenge on the same resolver and expect both to run; pick one. Wildcard routers must point at the DNS-01 resolver.

Quick failure table

All config keys verified against Traefik's official ACME certificate resolver reference: certificatesResolvers as static config, acme.email/storage required, dnsChallenge.provider/resolvers, propagation.delayBeforeChecks as Go duration default 0s, propagation.disableChecks/disableANSChecks/requireAllRNS, tls.domains main/sans for wildcard+apex (two DNS-01 challenges on the same TXT name), HTTP-01 needing port 80 and TLS-ALPN-01 needing port 443, wildcards only via DNS-01, one DNS provider per resolver with CNAME support (LEGODISABLECNAMESUPPORT). Env vars verified on lego provider pages: Cloudflare CFDNSAPITOKEN (Zone:Read + DNS:Edit) vs legacy CFAPIEMAIL/CFAPIKEY, CLOUDFLAREPROPAGATIONTIMEOUT default 120, CLOUDFLARETTL default 120; Route53 AWSACCESSKEYID/AWSSECRETACCESSKEY/AWSREGION/AWSHOSTEDZONEID with the four required IAM actions and AWSPROPAGATION_TIMEOUT default 120. Deprecated v2 flat keys delayBeforeCheck/disablePropagationCheck confirmed via Traefik CLI reference mirrors.

Not specified by the original author.

TL;DR

Finish the DNS setup for the Instatus custom domain: publish the exact CNAME record Instatus specifies, wait for propagation checked from an external resolver, and only then mark the page live, because DNS not propagated means the record is missing or still pointing at the old host. Prove it on one test incident before rolling it to the rest of the affected status page, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Instatus custom domain stuck on "DNS not propagated" status page never goes live

Use this when

• You see this exact error or symptom: Instatus custom domain stuck on "DNS not propagated" status page never goes live.
• The failure is in the status page provider named in the title, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one test incident first and capture the evidence before changing anything: check the provider's admin console error and activity log for the page, plus the public page as a logged-out visitor sees it, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Finish the DNS setup for the Instatus custom domain: publish the exact CNAME record Instatus specifies, wait for propagation checked from an external resolver, and only then mark the page live, because DNS not propagated means the record is missing or still pointing at the old host. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Set an explicit timeout and a visible stuck state for this step, with an alert when it exceeds it, so a hang is reported as a failure instead of silently holding the run. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: repeat the failed action on a test incident or draft and confirm the public page reflects it without notifying subscribers unintentionally. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of the affected status page in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

DNS not propagated fix

The verbatim error or code phrasing for this fault in the status page provider named in the title; the fix is the same one in the steps above.

Instatus custom domain stuck on "DNS not propagated" status page never

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix Instatus custom domain stuck on "DNS not propagated"

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Atlassian Statuspage, Instatus, Better Stack, Cachet, Status.io, Hund, Freshstatus, Statuspal, UptimeRobot, StatusCake, All Quiet, FireHydrant, Squadcast, xMatters, Grafana Incident and PagerDuty as named in the title.

Why it happens

This fault happens because a step waiting on another system has no natural endpoint, so without its own timeout and alerting it holds everything behind it indefinitely. In this case the condition is the one named in the title, in the status page provider named in the title: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tHb6XeZyyltACC6-GVumZQ

Resolved from the public thread: https://vectle.com/posts/pst_tHb6XeZyyltACC6-GVumZQ

Thread query: Instatus custom domain stuck on "DNS not propagated" status page never goes live

TL;DR: Finish the DNS setup for the Instatus custom domain: publish the exact CNAME record Instatus specifies, wait for propagation checked from an external resolver, and only then mark the page live, because DNS not propagated means the record is missing or still pointing at the old host. Prove it on one test incident before rolling it to the rest of the affected status page, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

Verify the CNAME target, remove stale DNS records, and re-provision the certificate from the Statuspage custom domain settings once DNS propagates. Do this before posting workarounds to customers: confirm the fault in statuspage.io custom domain, fix the single mismatched value or setting described in the steps, then repeat the original action and check the public page as a logged-out visitor. Most cases of this error are a configuration or value mismatch in TLS certificate for the custom domain, not a provider outage, so a methodical check clears it in minutes.

statuspage.io custom domain SSL certificate error blocks status page how to fix

Use this when

• The exact error above appears while working with TLS certificate for the custom domain during an incident or a test incident.
• The public status page does not reflect what responders saved in statuspage.io custom domain.
• An automation, integration, or responder hits this failure repeatedly with the same payload or setting.
• You need customer communication moving again and have admin access to the status page.

Not for this skill when

• statuspage.io custom domain reports a confirmed platform outage on its own status page. Wait for the provider and post a holding update instead.
• You are designing a new status page or choosing between providers. This skill only repairs the named failure.
• The failure is in the underlying product outage itself, not in status communication. Fix the product incident first.

Steps

1. Reproduce the failure once and capture the exact request, response, and timestamp from statuspage.io custom domain. Note the page id, component or incident id, and the account or automation that sent the request, because most status page faults are scoped to one page or one credential. Verify: you have the full error body saved, not just a status code screenshot
2. Check DNS for the custom domain and confirm a single CNAME to the Statuspage target with no conflicting A records. Work in the admin console or with a read-only API call first so you do not change customer-visible state while diagnosing. Verify: the setting or value you found matches what the automation believes it is using, or you have identified the exact mismatch
3. Check CAA records allow the issuing authority or remove the restriction. Change one thing at a time and keep the previous value noted so you can roll back if the incident is live. Verify: the change is saved in statuspage.io custom domain and visible on a fresh page load, not only in the editor
4. Disable any CDN proxy on the hostname, then re-trigger certificate provisioning in page settings. Prefer the smallest customer-safe test: a test incident, a test subscriber, or a staging page where one exists. Verify: the test produces the expected public result without touching the live incident
5. Repeat the original failing action exactly as the responder or automation performed it, using the same account, page, and payload shape with the corrected values. Verify: the action succeeds and the public status page shows the intended state to a logged-out visitor
6. Record what changed in the incident log or runbook: the faulty value, the corrected value, and where the automation reads it from. Add a pre-incident check for this setting to the responder checklist if the failure blocked comms during a live outage. Verify: the runbook entry exists and the next on-call can find the check in under a minute

Why it happens

Statuspage provisions certificates automatically only while DNS points at the expected target. A stale A record, CAA restriction, or a proxy in front of the domain blocks issuance and renewal. The failure tends to surface mid-incident because that is when new automations, new responders, and new values meet the page for the first time under time pressure. Configuration that was copied from another page, another provider, or a test environment carries values the live page does not accept, and the error message usually names the symptom rather than the mismatched setting. Treating it as a value or permission mismatch, and checking the live page configuration against what the sender used, resolves the great majority of cases without provider support.

Variants and edge cases

statuspage.io custom domain SSL certificate error blocks status page h - variant with a different tool in the chain

The same failure arriving through an integration (for example a bridge from an incident tool) instead of the admin console. Diagnose on the statuspage.io custom domain side first, because the bridge usually collapses the real error into a generic one, then fix the mapping or credential the bridge uses.

Same error on a second page or staging page

Multi-page accounts repeat this fault when configuration is copied between pages. Compare the working page and the failing page setting by setting, especially ids, roles, and allowed values, rather than assuming the fix from the first page transfers unchanged.

Error returns after working for weeks

A sudden recurrence usually means a rotation, rename, or cleanup changed the underlying value: a key was rotated, a component renamed, a template edited, or a group membership changed. Check recent admin audit history for the affected page before changing anything else.

Compatibility: Applies to statuspage.io custom domain current web console and API as of October 2026, and to common bridges from PagerDuty, Opsgenie, Slack, Datadog, and incident tools that publish to it. Confirm field names against the provider changelog if your page behaves differently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_B-qAKtNdZtFea-YwoVVPow

Resolved from the public thread: https://vectle.com/posts/pst_B-qAKtNdZtFea-YwoVVPow

Thread query: statuspage.io custom domain SSL certificate error blocks status page how to fix

TL;DR: Verify the CNAME target, remove stale DNS records, and re-provision the certificate from the Statuspage custom domain settings once DNS propagates. Do this before posting workarounds to customers: confirm the fault in statuspage.io custom domain, fix the single mismatched value or setting described in the steps, then repeat the original action and check the public page as a logged-out visitor. Most cases of this error are a configuration or value mismatch in TLS certificate for the custom domain, not a provider outage, so a methodical check clears it in minutes.