Certs on origin servers...
I'm having issues reading https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/ properly. It states:
"Contains a Common Name (CN) or Subject Alternative Name (SAN) that matches the requested or target hostname."
... but I'm not sure if that's matching the CDN->origin request (which would make sense) or the client->CDN request (which I could understand, but I hope that's not the case)
Can anyone shed any light on the right way to interpret that?
I'm having issues with a Full (Strict) SSL connection where the hostname used by the client will absolutely not match anything in the certificate of the origin.
Please/thanks
Cloudflare Docs
Full (strict) | Cloudflare SSL/TLS docs
Similar to Full Mode, but with added validation of the origin server’s certificate, which can be issued by a public CA like Let’s Encrypt or by Cloudflare Origin CA.
8 Replies
So if you have a record like
CNAME pineapple.mycooldomain.com, targeting azureisslow.com
The cert could match either pineapple.mycooldomain.com (requested) or azureisslow.com (target) to be valid.
Of course, this doesn't do anything for A/AAAA records
I'm having issues with a Full (Strict) SSL connection where the hostname used by the client will absolutely not match anything in the certificate of the origin.Cf offers free 15 year certs under ssl/tls -> origin server, trusted by Proxy, works w/ full (strict) *doesn't do anything special for non-cname proxied records since there is no "Target hostname", only requested hostname
Oooooooh, that makes sense - I just didn't parse the sentence that way at all.
I have no control over the origin at all, so can't do anything with the certs there.
That said, although the certs on the origin don't match the client (pineapple in your example) they should match the target (azureisslow.com)
Does it check wildcards and SANs? or does 'match' mean CN==target with no variations?
Thank you @Chaika btw - this is really helping.
Does it check wildcards and SANs? or does 'match' mean CN==target with no variations?Yep it checks both, supports wildcards, exactly the same as browser would accept
There goes that idea then 🙂
Is there any way to diagnose which part of the origin cert isn't matching?
nothing easily within CF. I'd check if it's presenting the right certificate though
curl --resolve example.com:443:127.0.0.1 https://example.com/ -vvv -k
replace 127.0.0.1 with origin ip behind CF and website url too of course
If cert looks sane you could remove the
-k and fake both the requested hostname/target hostname and see if curl accepts eitherOrigin certs are sane - and in production with many users.
The 'how to setup with CloudFlare' docs do say to use 'Full' - but don't specify 'don't use Full (Strict)'.
Thank you for everything. Do you have a preferred tip-jar?
Full (Strict) is what you want to use though, otherwise anyone could MITM and serve any cert and it'd be accepted. You'd have end to end encryption to the attacker.
You're still getting a cert error?
yup.
It works where the CN=example.com and the origin is example.com
But not when the CN=*.example.com and origin is a.example.com
I can't isolate all the variables, but this is a big pointer.
