Which domain are users seeing this error on? Several of your root domains (picarrier.com, kibind.dev, mathmogged.com) currently resolve to name.com A-record IPs instead of pointing to Railway via a CNAME, which means visitors hitting those IPs get name.com's TLS certificate rather than yours, causing the NET::ERR_CERT_COMMON_NAME_INVALID error. name.com's nameservers do not support CNAME flattening at the apex, so you would need to either switch your nameservers to a provider that does (e.g. Cloudflare) and set a flattened CNAME pointing to the Railway target shown in your service's custom domain settings, or use the www subdomain (which already works correctly for www.picarrier.com) as your canonical URL.

• picarrier.com is already fixed.

• Keep the ANAME @ → yeijkfa6.up.railway.app record shown.

• Name.com does support ANAME/CNAME flattening at the apex; the earlier warning was incorrect. Name.com documentation

  (https://www.name.com/support/articles/115010493967-adding-an-aname-alias-record)

• Railway reports picarrier.com and www.picarrier.com as ACTIVE, verified, and certificate-valid.

• Both URLs return HTTP 200 with valid matching TLS certificates.

• Cloudflare or a nameserver change is unnecessary. Railway explicitly supports ANAME records for root domains. Railway documentation

  (https://docs.railway.com/networking/domains/working-with-domains)

If anyone still sees the old certificate error, it is cached DNS. The current TTL is 300 seconds, so restart their browser or flush DNS

and retry after several minutes. No DNS changes are needed now.

This was on our end, not your DNS. A race in how certificates get distributed to our edge nodes could leave a stale certificate on some of them, which is why the error appeared from some regions and not others. The trigger was adding a domain, removing it, then adding it back.

The underlying fix is deployed, and we regenerated the certificates for both your apex and www domains so they land correctly across the edge. Both now serve valid certificates.

Your ANAME setup was correct, and the earlier reply about nameserver changes was wrong. Cloudflare in front is optional at this point, so keep it or remove it as you prefer.