Hi,
I have a site hosted in AWS behind CloudFront, and am getting SSL 525 handshake errors when attempting to use a proxied connection through Cloudflare.
When going direct to the CloudFront entry, things are working fine.
When proxying via Cloudfront, the 525 error is being presented by Cloudflare.
We have an SSL cert deployed to CloudFront, and have all the standard settings enabled.
Why are we seeing a handshake error when proxying via Cloudflare, but not when going direct to CloudFront?
Out Cloudflare settings are ‘SSL Full (strict)’.
I have searched around for an answer to this, and do not seem to be able to find a suitable answer.
A 525 indicates SSL does not work at all. If you say direct connections work, the most likely explanation would be some firewall on Amazon might prevent Cloudflare from establishing a proper SSL connection.
Not on the CloudFront distribution, as we are only able to attach a single cert to CloudFront, and don’t want all our brand sites listed as Subject alternate names on that cert - this is the reason for going via CloudFlare, where we can have multiple proxied CNAME entries, each protected by a CloudFlare SSL cert.
Fair enough, you wouldn’t necessarily need a certificate for that domain in the case of a CNAME on Cloudflare, however your server should still return something and it seems it does not
$ openssl s_client -connect [ORIGIN]:443 -servername mako-ven1-dev.jumpmandnsautomationtest.com
CONNECTED(00000003)
3069501440:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252:
---
no peer certificate available
That is really strange, as when hitting the direct site via a browser, we get a valid certificate.
I will do some more research.
Out of curiosity, when attempting that command on my Mac Laptop, or on our Ubuntu VM, we get address lookup errors, any ideas what might be causing that!? Pretty certain that is not related though.
Yeah, just tried it as CNAME on SSL and got a 525 too. You’ll need to configure your server to respond to requests WITH THAT HOSTNAME with a certificate either valid for your actual domain or at least for the CNAME. Right now it seems to return the certificate only when you connect with the direct hostname. The moment you try to establish an SSL connection with the proxied hostname it just says no, thanks
Hmm, that’s frustrating. We had assumed that using the proxy version would mean that Cloudflare would establish it’s own connection to our backend, which would then allow the handshake between those two endpoints, hiding the actual cert on CloudFront from the user.
maybe we have missunderstood how this all should work?
If we change Cloudflare to bypass CloudFront and go direct to the LoadBalancer, our pages work correctly and have no problems with the certificate, even though the certificate presented is not for the CNAME.
Which makes even less sense!
With Cloudflare configured with a CNAME proxy to the load-balancer, which also does not have a certificate for the mako-ven1-dev.jumpmandnsautomationtest.com domain, it works as expected.
It is only when we swap that to go to CloudFront we get the issue.
Ah yes, I see.
Yes, we did try that, and just configured as a regular CNAME which did not work - that was expected as I know the SAN on the cert does not cover that name. We were hoping to get around that by enabling the proxy feature.
