SSL Error 525 with Proxied CloudFront origin

Security
#1

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.

Thanks in advance,
Dave

#2

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.

What’s the domain?

#3

HI,
This is the direct-to-cloudfront domain - https://mako.ven1.dev.jumpman.uk/
This is the proxied-via-cloudflare domain - https://mako-ven1-dev.jumpmandnsautomationtest.com/

The direct works fine, and has a valid SSL cert, the proxied fails, which we did not expect given that the direct is working.

There is no WAF on the CloudFront distribution, and the SecurityGroup for the origin load-balancer is open to all.

Thanks!

#4

Is there a proper certificate configured for mako-ven1-dev.jumpmandnsautomationtest.com?

#5

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.

#6

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
#7

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.

#8

How is mako-ven1-dev.jumpmandnsautomationtest.com configured? As CNAME record for mako.ven1.dev.jumpman.uk?

#9

Did you substitute the ORIGIN address correctly? I redacted that.

#10

Yes, configured in Cloudflare as a CNAME, with Proxy enabled, not just a pass-through.

My mistake with the openssl command, I have a response now, thanks!

#11

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 :slight_smile:

#12

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?

#13

Cloudflare does establish such a connection, but Cloudflare can’t do anything either if your server returns an error which it currently does.

#14

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! :cry:

#15

If you unproxy the record right now, it won’t work either.

#16

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.

#17

Did you unproxy the mako-ven1-dev.jumpmandnsautomationtest.com address? If you do it shouldn’t work either.

#18

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.

#19

The proxy can’t fix the SSL issues on your server. You will need to fix the SSL configuration on your server.

#20

I have just tried creating the following proxy configuration in Cloudflare, which CNAMEs direct to our Load Balancer


And that works fine.

The only difference is that the origin for the entry that works in an ALB, the origin for the entry that fails is CloudFront.

Really strange. Maybe it is some option within CloudFront that is failing to handshake correctly?