Why does one of these certificates come from Cloudflare and the other one comes from Google? They also have different validity lengths. Is this expected?
SSL Certificate Expiration Dates, Issuers, and "Full (Strict)" Setting
I’m also unable to enable “Full (Strict)” SSL mode on RyderCragie.com due to this:
However it works on Ryder.link perfectly:
How do I get them both to be from sni.cloudflaressl.com?
Different certificate authorities have different maximum validity periods. For example, Google Trust Services has a maximum of 3 months while DigiCert has a maximum of 1 year. The certificate for
ryder.link is not really issued by Cloudflare, rather, it is issued by a branded subordinate CA managed by DigiCert.
You don’t. It would not fix the issue as the error you are seeing on
anything.rydercragie.com has nothing to do with who issued the edge certificate.
To fix the issue you need a valid certificate for
anything.rydercragie.com on your origin server. I recommend you pause Cloudflare on the domain until you are able to connect to your origin server over HTTPS.
You either have a valid certificate for
anything.ryder.link on your origin server or the SSL mode is not set to Full (strict).
They’re both configured in exactly the same way. Cloudflare just so happens to have given RyderCragie.com a GTS cert and Ryder.link a Cloudflare cert, so that’s why RyderCragie.com get’s an error. They’re both set to “Full (Strict)”. I really don’t understand why they’ve issued a Google cert for RyderCragie.com as both domains are set up in the same way.
I need Cloudflare to issue an sni.cloudflaressl.com cert for RyderCragie.com just like it did for Ryder.link.
Trust me, it is not. If there was an issue with the edge certificate for
rydercragie.com your browser would not even let you connect to Cloudflare’s servers. As the error you are seeing is being returned by Cloudflare, you have already successfully connected to Cloudflare’s servers. If you take a look at the “What happened?” section on the page, you will see that “The origin web server does not have a valid certificate.”
Cloudflare uses multiple certificate authorities to issue edge certificates. You cannot choose the certificate authority unless you purchase Advanced Certificate Manager. But like I have already said, the edge certificate issuer has nothing to do with the error you are seeing.
When using the Full (strict) SSL mode, Cloudflare requires that the origin server presents a valid certificate for the domain. This certificate is separate from the edge certificate.
Client <---[Edge Certificate]---> Cloudflare Server <---[Origin Server Certificate]---> Origin Server
If your origin server only has a certificate for
ryder.link, it will naturally not be valid for
rydercragie.com, causing Cloudflare to return this error.
rydercragie.com have the same origin server, you may be able to solve the issue by replacing the A/AAAA records on
rydercragie.com with a CNAME record pointing to
ryder.link. This is due to the way Cloudflare validates origin server certificates (it accepts certificates valid for the domain name or the CNAME target the domain points to).
The really ironic thing is, though, is that *.rydercragie.com and *.ryder.link BOTH don’t have valid origin certificates, as the hosting provider on that wildcard (Proton) cannot provide wildcard certs. So again, why does *.ryder.link work but *.rydercragie.com doesn’t?
For reference, the wildcards on both domains are exactly the same record and they are both proxied. Universal SSL is also enabled for both. If you need anymore info please let me know.
I appreciate your help and the explanations you have given.
I cannot say without knowing the exact origin server configuration. I recommend you pause Cloudflare on
rydercragie.com so we can see what certificate the origin server is returning.
It’ll just be invalid and show a “Your connection is not private” message with an invalid cert for the * subdomain.
This is one of the reasons why I moved to Cloudflare - to fix the wildcard SSL. It works when I have it set to “Full” instead of “Full (Strict)”. I understand the reasoning now, with it being an invalid origin cert for both domains, but why *.ryder.link still works seems very strange to me. Why is Cloudflare accepting that invalid origin cert then?
Happy to change it back to “Full”, but I’d rather fix this if possible rather than use a loophole and lower the security (since that’s the whole point of Cloudflare).
I can unproxy both wildcard records and change the setting back to “Full”, if this will allow us to see the origin certificate in a browser rather than pausing Cloudflare altogether?
Never mind. My browser was caching the cert. I’ve flushed the DNS and now they both show as invalid, so NOW it makes sense.
Will change both domains back to “Full”. Thanks for your help!
If the origin server has a valid certificate for
ryder.link but not
*.ryder.link, you can replace the A/AAAA record on
*.ryder.link with a CNAME record pointing to
ryder.link. You should then still be able to use Full (strict) due to how Cloudflare validates the origin certificate. The same should work for
ryder.link IN A 192.0.2.1 *.ryder.link IN CNAME ryder.link
Full SSL mode is not secure so I strongly recommend you try the method I described above.
Oh wow. Never knew you could do that. Let me try!
Just changed that over now - using robots.txt as an example file, can you access both now?
Neither, actually. The former returns an origin SSL certificate error while the latter returns a connection error (HTTP 522). Could you send a screenshot of your current DNS records on both domains?
I saw that error too, but I think it’s working now. Can you try again please?
Oh wait - silly me. For both domains, the root doesn’t point to Proton - only the wildcards.
Will have to change both to “Full” by the looks of it and change the records back.
As you might have noticed,
www.ryder.link work fine while
whatever.ryder.link does not. The reason for this is that the origin is a shared hosting provider that uses the SNI to determine which certificate to use. The server only accepts
www.ryder.link - an SNI of
whatever.ryder.link causes the server to return a certificate for
invalid-ssl-configuration.short.io which Cloudflare naturally doesn’t consider valid for
$ openssl s_client -servername ryder.link -connect cname.short.io:443 2>/dev/null | grep 'subject' subject=/CN=ryder.link $ openssl s_client -servername www.ryder.link -connect cname.short.io:443 2>/dev/null | grep 'subject' subject=/CN=ryder.link $ openssl s_client -servername whatever.ryder.link -connect cname.short.io:443 2>/dev/null | grep 'subject' subject=/C=US/ST=Delaware/L=Wilmington/O=Short.io/CN=invalid-ssl-configuration.short.io
As for why
whatever.rydercragie.com returns a connection error, that is because you are using
rydercragie.com as a Workers Custom Domain. Workers Custom Domains point to a “discard address” internally, so creating a CNAME record pointing to a Workers Custom Domain will cause a connection error.
To sum it up, your hosting provider’s setup is not compatible with the “CNAME trick”.
That said, I do have some other subdomains on RyderCragie.com that are pointed to Proton with valid SSL’s, so maybe I could use this trick in that way?
static.rydercragie.com is set up with Proton, so if I point *.rydercragie.com to static.rydercragie.com and set it to “Full (Strict)”, would that work?
Does it matter whether Proton has issued the cert to static.rydercragie.com or rydercragie.com? Can’t recall which one they’ve issued it for that subdomain when you look in the “Common Name” field.
Please let me know @albert and I am happy to go forward with this.
I’ve changed it all back to “Full” and the old DNS records for the time being.
Yeah, it was me being stupid. The roots don’t point to Proton. They used to a couple of years ago which is probably why I thought that.
The “CNAME trick” does not really work for shared hosting. Even if you use Full non-strict, Proton still probably handles requests using the
Host header (which would still be
whatever.rydercragie.com even if
*.rydercragie.com points to
static.rydercragie.com). Unless you configured Proton to accept
*.rydercragie.com, Proton would not know how to handle requests for