Hi team — a wildcard custom domain is stuck issuing its TLS cert. The apex and a

dedicated subdomain on the SAME service issued fine, so DNS/routing is correct on my

side and only the wildcard's Let's Encrypt order is stuck.

PROJECT / SERVICE

• Project: cova-hrms (id 4195c229-a094-4373-9393-14760a995bab), workspace "Cova"
• Service: web (id a771aa27-e0c3-4756-993f-ea326ae61c2a)
• Environment: production (id 60c0e920-da6b-479e-96a1-c5380db7a436)

STUCK DOMAIN

• *.cova.sg (custom domain id d80b34fb-f4cf-420c-958f-f01de7e0a47d)
• Status: CERTIFICATE_STATUS_TYPE_ISSUING / CERTIFICATE_STATUS_TYPE_DETAILED_POLLING_AUTHORIZATIONS
• Verified: yes. Stuck 3+ hours.

WHAT WORKS (so DNS/routing is fine)

• Apex cova.sg -> cert valid (CN=cova.sg), HTTP-01.
• Dedicated demo.cova.sg -> cert valid (CN=demo.cova.sg), HTTP-01.
• Only the *.cova.sg wildcard (DNS-01) is stuck.

DNS (Cloudflare, all DNS-only / NOT proxied)

• •           CNAME -> seq68vnh.up.railway.app

• _acme-challenge CNAME -> seq68vnh.authorize.railwaydns.net
• _railway-verify TXT -> railway-verify=a05f9cb61bac28cca97fc6f707335c92c3569106c2b5fdaf780d26e6797c2e48

LIKELY CAUSE: STALE CHALLENGE TOKENS

Querying _acme-challenge.cova.sg returns OLD tokens from a previous order:

zmKWwfk37BWDEVMrk_7E72-gc-96j_VhUAIj1gX8slU

CEvz6mmHzDsGiDy_-sy5J5AnZm9nleKkANLkFmZnnuA

...but the current challenge host seq68vnh.authorize.railwaydns.net serves:

ZPtVtHt4LjorTr0IGad4_Y1rWPX0Coxxzm20oJnKK3w

So Let's Encrypt appears to be validating against stale tokens that don't match the

current order.

ALREADY RULED OUT / TRIED

• No CAA records on cova.sg. DNSSEC not enabled (no DS, AD=false).
• Cloudflare proxy is OFF (grey) on * , _acme-challenge, and apex.
• _acme-challenge / authorize.railwaydns.net CNAME are NOT proxied.
• Deleted + re-added the wildcard once (old target sx8p4xbk -> new seq68vnh); still stuck.
• Not re-adding again to avoid the Let's Encrypt duplicate-certificate weekly rate limit.

ADDITIONAL CONTEXT

• Pre-empting the common first reply: the ownership TXT is correctly at

  _railway-verify.cova.sg (railway-verify=a05f9cb6...), NOT misplaced on _acme-challenge,

  and Railway already reports "Verified: yes" for *.cova.sg. This is NOT a

  verify-record-placement issue.

• Wildcard ROUTING is fine: arbitrary .cova.sg already return HTTP 200 from the

  service over the placeholder *.up.railway.app cert (no x-railway-fallback header).

  The ONLY missing piece is the Let's Encrypt *.cova.sg certificate.

• This matches prior staff-resolved threads where only a Railway-side reset of the

  internal ACME state cleared a stuck wildcard (e.g. "subdomain/wildcard stuck at

  Issuing TLS certificate" and the 2025 "stuck-at-issuing-tls-certificate" tickets).

ASK

1. Please clear the stale ACME challenge tokens / reset internal ACME state for

   *.cova.sg (domain id d80b34fb-f4cf-420c-958f-f01de7e0a47d) and re-fire issuance.

2. Confirm whether I've hit the Let's Encrypt duplicate-cert rate limit for *.cova.sg

   (and if so, when it resets).

Thanks!