3 hours ago
Project: ptokit (819ce341-34d7-448e-824d-ee7b31349428)
Service: web
Environment: production
Domain: *.ptokit.app
Domain ID: 57723393-430b-4de9-95d9-998edc63b59e
Timeline:
- Domain added around 2026-09-16 23:43 UTC. DNS verified immediately (Verified: yes).
- Both required DNS records were created in Cloudflare right away and confirmed resolving correctly from multiple external resolvers (1.1.1.1, 8.8.8.8):
- CNAME * → fzu7cchs.up.railway.app
- CNAME _acme-challenge → fzu7cchs.authorize.railwaydns.net
- Also confirmed there's no CAA record on ptokit.app that would block certificate issuance.
- Certificate status sat in ISSUING / POLLING_AUTHORIZATIONS for roughly 90 minutes with no progress.
- It then surfaced as failed in the dashboard: "Failed to issue TLS certificate — An internal error occurred. Please retry or contact support."
- Ran railway domain certificate retry "*.ptokit.app" via CLI. The retry was accepted and the status returned to ISSUING / POLLING_AUTHORIZATIONS, but it's now been sitting in that same state again for [however long it's been since your retry] with no further progress or error.
Question: Since DNS is confirmed correctly configured and the error was reported as CERTIFICATE_ERROR_TYPE_INTERNAL (not a DNS/validation failure), could you check what's happening on your side for this certificate order — and whether repeated issuance attempts for this domain might be hitting a Let's Encrypt rate limit that isn't being surfaced clearly?
For reference, our apex domain ptokit.app on the same service went through a similar slow-issuance delay earlier before eventually succeeding, so this may be a recurring pattern specific to this account.
1 Replies
3 hours ago
Your wildcard domain's DNS records are correctly configured on our side (both CNAMEs propagated and verified), but our probe of the ACME DNS-01 challenge path shows a provider-side conflict: Cloudflare's authoritative nameservers are serving their own TXT values at the challenge record that don't match the values at our delegation target, which is what's blocking the certificate authority from validating. This happens when Cloudflare manages hidden certificate-related TXT records (for its own Universal or backup certificates) that conflict with the delegated validation. A recursive resolver may follow the CNAME and see the correct token, which is why your public-resolver checks looked fine, but the CA queries authoritative nameservers directly and gets the conflicting values instead. Cloudflare needs to resolve that conflict on their side - you can provide them with the evidence that their authoritative nameservers are returning TXT values that don't match the delegation target for the ACME challenge record, and point them at their documentation on conflicting ACME TXT records. Once Cloudflare resolves the conflict, a fresh certificate issuance attempt will be needed since the existing authorization is terminal - you can trigger that from the domain's row in your service's Settings.
Status changed to Awaiting User Response Railway • about 3 hours ago