a month ago
Project: b5d3e982-f524-4971-8752-708d4e179f40 (lattice-platform)
Service: womaris-frontend — 801f5f7d-15af-4f95-acfb-5c7b50a6d113
Environment: production — 3ca266b3-1726-4dbf-988c-e053e180b9cc
Domain: www.cleverscopemed.com — id 449142f9-28cc-4214-899a-63e53a9fc597
SUMMARY
Two custom domains for the same hostname have each sat in
CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for about an hour and never issued.
The service is healthy and serves correctly on its own *.up.railway.app hostname
throughout. Requests to the custom domain return the "train has not arrived at the
station" page, and TLS presents the CN=*.up.railway.app wildcard rather than a
certificate for the hostname.
CURRENT STATE — your API reports the record as propagated and matching, and
issuance still does not proceed:
currentValue: j5pdrqxk.up.railway.app
requiredValue: j5pdrqxk.up.railway.app
status: DNS_RECORD_STATUS_PROPAGATED
certificateStatus: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP
certificateErrorType: null
certificateRetryable: null
DNS IS CORRECT AND INDEPENDENTLY VERIFIED
www.cleverscopemed.com -> CNAME j5pdrqxk.up.railway.app, TTL 600, identical on:
-
authoritative: ns23.domaincontrol.com, ns24.domaincontrol.com
-
Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9,
OpenDNS 208.67.222.222, Verisign 64.6.64.6
No resolver anywhere returns any other value.
HISTORY
-
Domain 8ae1517d-5dec-4e1c-b003-f0ab8593c55e created, target
h8gax82t.up.railway.app. DNS pointed at it correctly. Stuck ~1 hour.
-
During that period the API alternated between currentValue h8gax82t (correct
at the time) and cleverscopemed.com (a stale prior value) across consecutive
polls, reporting DNS_RECORD_STATUS_PROPAGATED in both cases.
-
Deleted and recreated as 449142f9-..., new target j5pdrqxk.up.railway.app.
DNS updated, TTL lowered to 600.
-
For ~40 minutes the API reported currentValue h8gax82t — the DELETED domain's
target, which by then no resolver on the internet was serving.
-
It has since settled on currentValue == requiredValue and remains stuck.
customDomainIssueCertificate called four times across both domains. Every call
returned true; none changed the state.
RULED OUT ON OUR SIDE
-
DNS: verified across six independent resolvers plus authoritative.
-
ACME reachability: /.well-known/acme-challenge/* is not intercepted by our
app; it returns 404 from the edge and our middleware does not redirect that
prefix. Verified on the deployed build.
-
Service health: / returns 200 on the *.up.railway.app hostname continuously.
-
Any proxy in front: no CDN or other provider is bound to this hostname.
"TRAIN HAS NOT ARRIVED" REQUEST IDS
qc7yJFk4R0KnekEXCYBc-A
PsuJaMEFQJOF2nh8-_9nXA
M6J4z-RxQ926-Pr0nPRhug
ASK
Please force revalidation / reissue server-side for domain
449142f9-28cc-4214-899a-63e53a9fc597, or advise what is blocking ownership
validation. We would prefer not to delete and recreate a third time: each
recreate mints a new CNAME target and requires another registrar change, and two
attempts have now failed identically.
1 Replies
a month ago
The domain's CNAME is propagated correctly, but the TXT verification record is missing, which is why it stays in VALIDATING_OWNERSHIP. Custom domains require both a CNAME record for routing and a TXT record for ownership verification, and certificates will not issue until the TXT record is in place. Add a TXT record at the hostname shown in your service's Settings under Networking (the verification record name and value are displayed alongside the CNAME target) at your DNS provider, and verification will proceed once it propagates.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 28 days ago