2 months ago
Custom domain api.quillreply.com will not finish certificate issuance.
Project: quillreply-api (05482710-b90b-48e3-9576-92e8a90a48e4)
Environment: production (89604b73-d12e-46d6-83cc-24de13b884e6)
Service: api (011327f8-f4ab-4510-84da-5cd595ad864a)
Domain: api.quillreply.com (825b5a14-fe83-406a-8d4e-dacb91be977d)
CNAME target assigned by Railway: y0wevrmo.up.railway.app
Your own API reports the DNS record as satisfied but the certificate as not
issued, and ownership as unverified:
dnsRecords[0].status = DNS_RECORD_STATUS_PROPAGATED
dnsRecords[0].currentValue = y0wevrmo.up.railway.app
dnsRecords[0].requiredValue = y0wevrmo.up.railway.app
dnsRecords[0].purpose = DNS_RECORD_PURPOSE_TRAFFIC_ROUTE
certificateStatus = CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP
verified = false
verificationDnsHost = _railway-verify.api
verificationToken = railway-verify=8b7ce3fd...
That state has persisted for more than 24 hours.
What I have already verified on my side:
-
Public resolvers agree with Railway. api.quillreply.com CNAMEs to
y0wevrmo.up.railway.app, which resolves to 69.46.46.85.
-
The record is DNS-only in Cloudflare, not proxied. The hostname resolves
to a Railway address rather than a Cloudflare one, which confirms it.
-
There are no CAA records on quillreply.com or on api.quillreply.com, so
nothing is restricting Let's Encrypt issuance.
-
I have already deleted and re-created the custom domain once. The current
id and CNAME target above are from that second attempt, and Cloudflare was
updated to match. The service has been redeployed since.
The observable symptom at your edge:
Your edge accepts TLS for api.quillreply.com but presents Railway's own
wildcard certificate rather than one for my hostname:
subject = CN = *.up.railway.app
issuer = C = US, O = Let's Encrypt, CN = YE1
valid = Jul 29 2026 to Oct 27 2026
That wildcard does not match api.quillreply.com, so client verification fails
and no HTTP response is ever returned. Plain HTTP to the same host returns 301
to the https URL, so there is no working path. The service itself is healthy
and serving normally on api-production-83ae.up.railway.app.
What I think the actual issue is:
status.verified is false, and the verification host you specify is
_railway-verify.api. I cannot create that TXT record. api.quillreply.com holds
the CNAME you require, and Cloudflare will not serve any record beneath a name
that holds a CNAME.
I verified this rather than assumed it. In the same zone, a TXT record at
_cnametest.quillreply.com, which has no CNAME above it, resolved from your
assigned nameservers within 45 seconds. A TXT at
_railway-verify.api.quillreply.com returned NXDOMAIN from those same
nameservers for over five minutes, even though the Cloudflare API confirms the
record exists in the zone.
So the requirement appears to be a CNAME at "api" and a TXT under "api" at the
same time, which DNS will not allow.
Worth noting that status.dnsRecords lists only the CNAME, with purpose
DNS_RECORD_PURPOSE_TRAFFIC_ROUTE and status DNS_RECORD_STATUS_PROPAGATED. The
TXT is not listed as a required record anywhere in that response.
My questions:
-
Is the _railway-verify TXT actually required for this flow, or is it only
used for pre-verification or for wildcard domains?
-
If it is required, how is it meant to coexist with the CNAME you require at
the same label?
-
If it is not required, what is the ownership check still waiting on, given
the CNAME is propagated and pointing at the target you assigned?
I would rather not delete and re-add the domain a third time, since I
understand that risks a Let's Encrypt failed-challenge backoff.
Pinned Solution
2 months ago
The _railway-verify TXT was not required for this certificate issuance. The CNAME was propagated and the certificate was eventually issued successfully, Railway completed ownership validation through another mechanism which was the CNAME itself.
For short: What validated the ownership here was the CNAME and the TXT does not need to be present.
5 Replies
2 months ago
Your domain api.quillreply.com is now fully working: the certificate status is VALID, ownership is verified, DNS is propagated, and edge routes are installed. The verification TXT record at _railway-verify.api.quillreply.com is resolving correctly with the expected token, so the CNAME/TXT coexistence concern you raised appears to have been handled by Cloudflare after all. You should now see your own certificate served instead of the Railway wildcard.
2 months ago
This thread has been marked as private.
Status changed to Awaiting User Response Railway • about 2 months ago
2 months ago
Confirmed working on my end, thank you. api.quillreply.com now serves a
certificate for itself (Let's Encrypt, CN = api.quillreply.com) and returns
200 over HTTPS.
One correction for the record, since it may matter at renewal and may help
the next person who searches this up. The _railway-verify TXT record is not
resolving. I re-checked after your message, both against the Cloudflare
nameservers assigned to this zone (piers/thea.ns.cloudflare.com) and against
8.8.8.8, and it still returns NXDOMAIN. The CNAME at "api" continues to
shadow anything beneath it, which is what I demonstrated earlier with the
control record in the same zone.
So whatever satisfied the ownership check, it was not that TXT. That is
consistent with status.dnsRecords only ever listing the CNAME.
My one remaining question: what actually validated ownership here, and does
renewal depend on the TXT being present? If it does, this will fail again
around November 16 and I would rather know now than find out from a browser
warning.
Thanks!
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
This is a question the Railway community is better placed to answer than support: people who have already worked this out on their own projects and can tell you what actually worked.
So we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who answers it, and threads like this usually get picked up quickly.
Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.
- Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
- Keep it private and close the thread - Nothing becomes public and the thread closes.
Status changed to Awaiting User Response Railway • about 2 months ago
2 months ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 2 months ago
1mikehall
Confirmed working on my end, thank you. api.quillreply.com now serves a certificate for itself (Let's Encrypt, CN = api.quillreply.com) and returns 200 over HTTPS. One correction for the record, since it may matter at renewal and may help the next person who searches this up. The _railway-verify TXT record is not resolving. I re-checked after your message, both against the Cloudflare nameservers assigned to this zone (piers/thea.ns.cloudflare.com) and against 8.8.8.8, and it still returns NXDOMAIN. The CNAME at "api" continues to shadow anything beneath it, which is what I demonstrated earlier with the control record in the same zone. So whatever satisfied the ownership check, it was not that TXT. That is consistent with status.dnsRecords only ever listing the CNAME. My one remaining question: what actually validated ownership here, and does renewal depend on the TXT being present? If it does, this will fail again around November 16 and I would rather know now than find out from a browser warning. Thanks!
2 months ago
The _railway-verify TXT was not required for this certificate issuance. The CNAME was propagated and the certificate was eventually issued successfully, Railway completed ownership validation through another mechanism which was the CNAME itself.
For short: What validated the ownership here was the CNAME and the TXT does not need to be present.
2 months ago
Confirmed working, and thanks for the follow-up.
Recording the resolution for anyone who finds this thread with the same
symptom: the certificate was issued once the CNAME propagated. The
_railway-verify TXT record was never required and never resolved in my
case, because the hostname holds the CNAME and Cloudflare will not serve
records beneath a CNAME'd name. If you are stuck at VALIDATING_OWNERSHIP
with a propagated CNAME, the TXT is likely a red herring.
Status changed to Solved mayori • about 2 months ago