Project orgscout-2-0 (37c515fd-b582-4da8-ab6b-478c1534e943), environment production, service

web (c435b3db-a1e0-4da5-b55b-e6fd42199c9f). Custom domain dev.orgscout.io, domain id

dd5c08f4-0c31-4dba-87b0-97e74501ebc4.

Your domains API reports:

• certificateStatus: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP

• DNS record DNS_RECORD_STATUS_PROPAGATED, requiredValue == currentValue == ludj4pt6.up.railway.app

  So DNS is correct and propagated by your own checks. On my side, all verified clean today:

• DNS-only (not proxied through Cloudflare), so Let's Encrypt reaches your edge directly. Edge IP resolves to 69.46.46.71.

• No CAA record on the orgscout.io zone (LE is not blocked).

• Direct cert probe: echo | openssl s_client -connect dev.orgscout.io:443 -servername dev.orgscout.io

  presents CN=*.up.railway.app with no SAN for dev.orgscout.io -> the per-domain cert was never

  issued, so every HTTPS client gets a name mismatch and dev.orgscout.io returns 000.

• The canonical origin web-production-76856.up.railway.app serves the same service at HTTP 200, so

  the service itself is healthy. Only the custom-domain certificate is stuck.

  This has persisted ~7 days (since ~2026-06-02), so it is not Let's Encrypt rate-limit backoff (those

  windows are hours to a week and have long since cleared). I have already tried removing and re-adding

  the domain (which only reset the ACME order, and generated a new target each time:

  pszzjifc -> xyq7r3cf -> ludj4pt6).

  Request: please inspect and reset the stuck ACME ownership-validation order for this custom domain

  on your backend, rather than asking me to recreate the domain again (recreating resets the order and

  burns LE attempts, and is likely why it is wedged). Happy to provide anything else you need.