Just saw that there is a warning sign next to my cname, could it be linked?

Though it seems weird that it'd work for 96% of people? And the other cloud is green

Hey, does hovering on the warning sign/icon reveal any information? I suppose that it could be related, although I am not sure myself given that I have never seen something like this before.

Nothing at all when hovering unfortunately :(

I just asked a team member and the warning sign/icon should not be an issue (I also checked one of my service's custom domain settings and it also has a warning sign/icon next to CNAME).

Unfortunately, I am also out of ideas, the last thing I would suggest is to remove the custom domain from Railway, delete the CNAME record on Cloudflare and redo the entire process of adding it to Railway, to see if this will fix the issue. The downside of this, is that you will most likely have a few minutes of downtime.

Arf too bad. Unfortunately I can't have the domain going down for an extended period of time as I'm offering a live service (especially not knowing if it'd even fix the issue).

From another post with a similar issue, I saw the following comment:
"Hi Pauline,

Nope, pretty sure it’s a railway issue… the pro strategy is to get a cloud-flare account (free) and set that up as a proxy so that cloud-flare handles your certs to client, since railway isn’t working right; there is a GitHub issue explaining more."

but the person has not been answering again. Would you be aware of such Github issue?

Update: tried running an openSSL test from my machine (from which I can access my website just fine) and got the following result:
- Verify return code: 20 (unable to get local issuer certificate)
- The chain stops at "GTS Root R4" and cannot verify to "GlobalSign Root CA"

Could that be the issue root cause?

Command I used: openssl s_client -connect cozycafe.thecozydeck.ch:443 -servername cozycafe.thecozydeck.ch

Hmm, I just ran the command in my terminal and it seem to be fine on my end with the verify return code being 0.

openssl s_client -connect cozycafe.thecozydeck.ch:443 -servername cozycafe.thecozydeck.ch </dev/null

Connecting to 66.33.22.208
CONNECTED(00000005)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R13
verify return:1
depth=0 CN=cozycafe.thecozydeck.ch
verify return:1
---
Certificate chain
 0 s:CN=cozycafe.thecozydeck.ch
   i:C=US, O=Let's Encrypt, CN=R13
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jan 25 17:27:32 2026 GMT; NotAfter: Apr 25 17:27:31 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=R13
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFCjCCA/KgAwIBAgISBXH3VH0a/hpZaEja4Jfcqx+zMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTMwHhcNMjYwMTI1MTcyNzMyWhcNMjYwNDI1MTcyNzMxWjAiMSAwHgYDVQQD
Exdjb3p5Y2FmZS50aGVjb3p5ZGVjay5jaDCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAJvrguPW5RA8+iMlCacJH4prtfuEJ7l9O1XvkERr9aJ+uXhggwS4
R6Do1SaUNLxtuaThIUAMIA+pGHhlwY+kRnZbKrk2g3be+EAm2yaj8uVn9Y6rxGso
/0Apl35Yz6g73e7orBF7NdbpMoB3DW07BNuxDpAL47uHE1B3VCJVw/NJIzLDn05I
Ra7g/BS680bN8iCxXZFUUrdFgdmzQzzOFEoKzqo3YVOvyDQkAj8k6sbMrDFCbYMx
S00jkB4ag61GnQE9n/pLLf+SYRcywizcxlAncm93QWCSHWYEN9cFQDItp314bCsA
g/8mz005nOcO335jOeD6sKnOWBXZ1/z81oECAwEAAaOCAicwggIjMA4GA1UdDwEB
/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/
BAIwADAdBgNVHQ4EFgQUBqn92uG6T9dU3nHk1/xkPNAerwEwHwYDVR0jBBgwFoAU
56ufDywzoFPTXk94yLKEDjvWkjMwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzAC
hhdodHRwOi8vcjEzLmkubGVuY3Iub3JnLzAiBgNVHREEGzAZghdjb3p5Y2FmZS50
aGVjb3p5ZGVjay5jaDATBgNVHSAEDDAKMAgGBmeBDAECATAuBgNVHR8EJzAlMCOg
IaAfhh1odHRwOi8vcjEzLmMubGVuY3Iub3JnLzUyLmNybDCCAQQGCisGAQQB1nkC
BAIEgfUEgfIA8AB2AMs49xWJfIShRF9bwd37yW7ymlnNRwppBYWwyxTDFFjnAAAB
m/Zn4yMAAAQDAEcwRQIgXidAzyPDNEtMk6FqTYLo8c5hxv08XD/aFNQybCp+pwcC
IQC3u+Bf/sepk1cuh4Ngl1+aDCeAQcP/MwGsYy6/I9XfGwB2ANFuqaVoB35mNaA/
N6XdvAOlPEESFNSIGPXpMbMjy5UEAAABm/Zn4/cAAAQDAEcwRQIhAJDE8Vir2WiS
zqBSlKK3XRGyxuif8hrqTxWhyk0sSC53AiBscJvRb5WN/9lcp9rcG2flBGg3MMRY
7KfdaWJlmc7iOjANBgkqhkiG9w0BAQsFAAOCAQEAnuvorvZMyCyReBLTYx8gzz7J
vkOp9iqJE20U+eSLJ2BynogzU2DYpx2gou2qwnbspQDnDSyGgrqUk24aJ+dqx5TI
Aww9jO9BxvQAddACdzXUD7SFicjzTtgLnrpQMDao/6/8DlKm+yZbFL0hWNyDJO6C
8CyD+SKLCmG0nI9GkehRs+qh2FpkBMjHF3YMAEVxMfgMU0P8wV/8MkduQxXFBaJ8
Hby2C94hWwQzlEA1ejI38wR2oH307yaddnFdKM2poIuSXfP8FJIWBCM9BKsmoKfx
RmidvqqZxgbUuCtrAnISAZOzIyZraIIPPTwyTOyfnOdj3jYvFVnhzINuOYGT9Q==
-----END CERTIFICATE-----
subject=CN=cozycafe.thecozydeck.ch
issuer=C=US, O=Let's Encrypt, CN=R13
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
---
SSL handshake has read 4216 bytes and written 1618 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Session-ID: 9D3C8D66EB64659937FB5905962DE5942F50CC3A459D583284549F8CBD072099
    Session-ID-ctx:
    Resumption PSK: 07758076DE063F2882504C69BCD9E9FE5B4A8193CAA023622A487F5C8A32991C
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 604800 (seconds)
    TLS session ticket:
    0000 - cf fc 12 0f 20 1c 9e 13-c6 3a a1 78 b3 15 e6 74   .... ....:.x...t
    0010 - cf 5f 81 af 48 a5 26 1e-50 b4 f5 dd b6 7c b1 54   ._..H.&.P....|.T
    0020 - c3 57 ef 9d 82 ae ac fc-b2 a1 28 d4 49 c7 69 fb   .W........(.I.i.
    0030 - 79 a1 88 2b 4c cd 8b 06-af 41 8c 38 ba 98 d1 2e   y..+L....A.8....
    0040 - 43 f6 2d ba 9b 9b e8 21-71 f1 a0 d9 10 71 38 de   C.-....!q....q8.
    0050 - 2b 15 ff f8 f0 2f dc ae-8b b0 27 bc d9 0a 42 62   +..../....'...Bb
    0060 - ca 63 1b 2b 95 de 51 a1-52                        .c.+..Q.R

    Start Time: 1770234720
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
DONE

Ok so not the cause of the error.

I tried pausing completely Cloudflare and it didn't improve the amount of users affected (even made it a little worse). So it seems it's on Railway side. I'm unsure of what else I can try to fix it as it seems network/SSL related and I don't have many settings i can try. Unfortunately the number of people affected is too high for me to just leave it as is. Is that an issue that's ever been seen before?

Update:

Sorry trying anything I can to solve this issue for the hundreds of daily impacted users

I've tried adding a new custom domain to send it to users and see if they get the same issue there. While doing that, I notice that the new domain has two lines of DNS records to add while my original only has one (it's missing the TXT). Could that be the rootcause? Am I supposed to have both CNAME and TXT for cozycafe.thecozydeck.ch as well? Because I do not right now.

Original on the left, test one on the right. (The value here is just placeholder as I don't know how sensitive this info is)

Hey, the TXT record does not have an effect on SSL as it is only used as another layer of verification to prevent domain hijacking (As in the rare case of you adding your domain to Railway, then removing it from Railway but leaving the CNAME record, then someone else using this exact domain with the CNAME record already set up and now being able to use your domain on their service).

Thanks for the answer.

So I've reached out to a few users which I knew were having issues with cozycafe.thecozydeck.ch
I gave them test.thecozydeck.ch (which has exactly the same settings as the other one, just an extra custom domain on railway) and it worked for them! (same cloudflare setup as well). So it confirms it's not their network, browser, firewall, etc..

Now the issue is, I cannot simply switch to another URL as users are using the URL for overlays, it's a bit complicated but basically i cannot fallback to test when cozy doesn't work or even supporting both and 95% of my user base is already using the first one.

So I tried deleting completely cozycafe and re-adding it to Cloudflare. I still see errors coming through in my analytics but I'm praying it's because it takes a while for users to update the DNS... Will update but also would be super interested to know if this is a known issue? Unfortunately this has taken a toll on my service as many users got scared when they saw that my website "wasn't secure" and I'd love to be able to give them a rational answer which I do not have for now

I believe that it is not a known issue for a correctly configured setup to have issues with SSL that would only affect a very small subset of users. SSL issues usually affect everyone that visits the domain in question (especially the case when the TLS certificate couldn't be issued).

Railway will actually show a modal if the TLS certificate couldn't be issued due to an error on Railway's end and will give you a way to retry it in your service's settings.

Thank you for your quick answer. I'm trying really hard to find where the setup could've gone wrong but have failed to find for the past 4 weeks and it's driving me crazy

Issue was happening before I added Cloudflare (actually added Cloudflare to try and mitigate this issue). I saw a few other threads mentioning a similar SSL protocol issue happening randomly to 5% of users but none of them have been resolved unfortunately

Deleting and re-adding the custom domain didn't fix it it seems, still seeing just as many errors popping up. Tho I deleted and re-added straight away to avoid down time as it affects my business directly but maybe I should have waited 5 minutes? Or does that make no difference?

Readding the domain should solve the issue most of the times, I am going to escalate your thread to the team to see if there is anything that can be done on Railway's side of things that would fix the SSL issue.

Looks like everything is working now?

Unfortunately not, I still see 5% of users getting SSL errors (I can see it in my analytics because I fetch data from the website from another one) and users are still reporting the same error screenshot to me

They all have modern browsers, no strong firewall, vpns, extensions, modern OS, they live in different parts of the world. test.thecozydeck.ch works for them but for 5% of users (which amounts to hundreds daily), cozycafe.thecozydeck.ch gets them this error. Let me know if you need screenshot of my cloudflare setup or anything that could help resolve it.

That last URL, cozycafe.thecozydeck.ch loads fine for me. As it only affects a small percent of people, it's likely a cache issue on their end.

What’d be the best way to fix their cache issue? I’ve asked them to try on incognito, clear browser cache or even different browser but it doesn’t fix it. Is there another cache at the machine level they should fix?

It'd depend on their machine and how their network is set up. This isnt a super uncommon bug so google would be the best place to sort it for their specific situation

Ok, so it wouldn’t be out of the ordinary that 1/20 person cannot access my website because of this ssl protocol error?

About the cache issue, would that usually stem from an ssl error on my side that was later cleared but stuck on the user’s cache? If so, wouldn’t it have cleared by itself one month later and would i not see a decreasing amount of issues with time?

I don’t mean to be pushy, just trying to best understand how I can avoid losing 1/20 user as most of them don’t even reach out to me but just stop using my service and move on

Since you're using Cloudflare with proxy enabled (orange cloud), Cloudflare handles the SSL certificates your visitors see, not us. The ERRSSLPROTOCOL_ERROR is happening at Cloudflare's edge before traffic reaches Railway, so this isn't something we can resolve on our end. You'll need to check your Cloudflare dashboard or contact Cloudflare support to investigate the edge certificate issue for that subdomain.

I added Cloudflare because I was having this error and hoped it'd fix it so it does not stem from them. I am more than happy to stop proxying so you guys can investigate!

I'm sorry, but the issue is not on our end. This issue is on the end of your users, which is something we cannot help with.