2 hours ago
I have two custom domains on separate projects in this account: bc.scottweierbach.com (Basecamp) and tally.scottweierbach.com (Tally). Both are proxied through Railway with Railway-issued Let's Encrypt certificates.
The two certs use completely different chains. Tally's: leaf (RSA) issued by "YR1", issued by "ISRG, CN=Root YR", issued by "ISRG Root X1" (terminal, 3 certs total). Basecamp's: leaf (ECDSA) issued by "YE1", issued by "ISRG, CN=Root YE", issued by "ISRG Root X2", cross-signed by "ISRG Root X1" (4 certs total).
On my Android phone, Chrome loads bc.scottweierbach.com fine, but WebAuthn (passkey registration) fails immediately with "NotAllowedError: WebAuthn is not supported on sites with TLS certificate errors." The exact same phone, same Chrome, registers passkeys fine on tally.scottweierbach.com. Chrome's WebAuthn implementation is known to be stricter about validating the full certificate chain than normal page loads, and this ECDSA chain with the X2/X1 cross-sign apparently doesn't validate cleanly in Chrome's path-building on this device, even though the RSA chain does.
Is the cert's key type (RSA vs ECDSA) something Railway's ACME client picks per-domain, and is there a way to request an RSA-chain certificate for bc.scottweierbach.com instead, to match the domain that already works? Happy to provide project/service/domain IDs if useful.
1 Replies
2 hours ago
We issue ECDSA P-256 certificates by default for all custom domains, and there is no option to request an RSA certificate instead. During an ongoing phase-out of RSA, some domains may still serve an RSA certificate alongside the ECDSA one until the older certificate ages out, which explains the difference you are seeing between the two domains. Both certificates are valid and publicly trusted, so a TLS client that rejects either has a chain-validation issue on its side rather than a certificate problem on ours.
Status changed to Awaiting User Response Railway • about 2 hours ago