Hi,

Thank you for the detailed report and troubleshooting steps.

Based on the information provided, DNS appears to be configured correctly:

• Wildcard CNAME (*.listeregalo.com) points to the current Railway target.
• _acme-challenge correctly delegates via CNAME to the Railway ACME validation target.
• DNS records are unproxied and publicly resolvable.
• No CAA restrictions have been identified.
• The apex domain (listeregalo.com) is issuing and serving certificates successfully.

Given that:

• The wildcard domain remains stuck in "Validating Challenges" or fails with "Failed to issue TLS certificate — An internal error occurred".
• The issue persists across multiple remove/re-add cycles.
• The target hostname changes on each re-add and DNS has been updated accordingly.
• TLS for subdomains continues to present the default *.up.railway.app certificate rather than a certificate covering *.listeregalo.com.

This suggests the failure may be occurring during the platform-side ACME issuance or certificate provisioning workflow rather than at the DNS layer.

To continue investigation, we recommend checking:

1. ACME challenge validation logs for the wildcard domain.
2. Certificate issuance worker/provisioning logs associated with the latest target (czobfn5y).
3. Any pending, failed, or orphaned certificate orders attached to the domain.
4. Platform-side rate limiting or issuance failures from the certificate authority.
5. Whether the wildcard domain is stuck in an incomplete validation state despite successful DNS resolution.

If internal tooling confirms successful DNS validation but no certificate has been issued, a manual reset of the certificate provisioning state and re-trigger of issuance may be required.

The current evidence indicates that the apex domain is functioning correctly and the issue is isolated to wildcard certificate issuance.

Thank you for your patience while we investigate further.

Thanks, but these are exactly the platform-side checks only the Railway team can perform — I've already verified everything on the DNS side. Could a Railway team member look at the internal provisioning state for target czobfn5y and re-trigger issuance?

Thank you

Update with a diagnostic that narrows this down to certificate binding, not DNS.

I inspected the certificate Railway serves for a wildcard subdomain of my domain (domain is DNS-only / grey cloud, so Cloudflare is not in the TLS path):

echo | openssl s_client -connect listeregalo.com:443 -servername test.listeregalo.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

Result:

subject=CN=*.up.railway.app

X509v3 Subject Alternative Name: DNS:*.up.railway.app

So Railway is presenting its default *.up.railway.app certificate — there is NO SAN covering *.listeregalo.com. The apex (listeregalo.com) has its own valid cert and works; only the wildcard cert was never bound.

To be explicit about what's already ruled out:

• Domain is DNS-only (grey) — Cloudflare is NOT proxying, so this is not the "proxied → Railway sees Cloudflare IPs" case.
• DNS verified: wildcard CNAME and _acme-challenge CNAME aligned to the current target (czobfn5y) and propagated; _railway-verify TXT correct; no CAA.
• Validation completes (apex issues fine), but the wildcard certificate is never provisioned/bound.

This matches the known wildcard cert-binding behavior where verification succeeds but the wildcard cert never gets attached, and only Railway can force-bind it server-side. Could a Railway team member force certificate provisioning/binding for the wildcard on this service?

Service: listeregalo (staging). Happy to provide the service ID.