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?
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).
3 Likes
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.
Assuming ryder.link and 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).
1 Like
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 rydercragie.com.
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.
3 Likes
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?
https://whatever.ryder.link/robots.txt
https://whatever.rydercragie.com/robots.txt
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, ryder.link and 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 ryder.link and 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 whatever.ryder.link.
$ 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”.
1 Like
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.
Lol. Brainfart.
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 whatever.rydercragie.com.