Creating a second HTTPS port on web host

I’m trying to connect an HTTP custom web service to be fronted as HTTPS on Cloudflare but not sure how to configure it.

I have a web host, with two web services:

  1. nginx with HTTP (80) and HTTPS (443), using Let’s Encrypt cert, working perfectly
  2. a custom web service with just HTTP (8443) and no HTTPS capabilities ← this doesn’t work

I need HTTPS on the custom web service. My Cloudflare TLS is set to “flexible” and to redirect all HTTP traffic to HTTPS. However, Cloudflare assumes that due to the port 8443 the service would have TLS.

Sending a POST query to Cloudflare on 8443 just gives me an error HTTP/1.1 525 Origin SSL Handshake Error.

How can I get, on top of my existing 80/443 services, a new web service on the same host (any port, doesn’t have to be 8443) which Cloudflare serves over HTTPS while my service is just via HTTP.

8443 is an SSL port, so probably not.

Right. It would do the same thing with 443.

Cloudflare provides free origin certificates, Let’s Encrypt provides free certificates, you can generate your own free certificate. You already have at least one cert on the origin. The ‘right’ answer is to just enable SSL on the new virtual server. Absent that, nginx can host multiple virtual servers on the same port so you can run this on port 80 as well.

3 Likes

Cloudflare provides free origin certificates, Let’s Encrypt provides free certificates, you can generate your own free certificate. You already have at least one cert on the origin. The ‘right’ answer is to just enable SSL on the new virtual server. Absent that, nginx can host multiple virtual servers on the same port so you can run this on port 80 as well.

The service is a custom web app which is not hostable via nginx. It’s a HTTP service which doesn’t have SSL capabilities.

Cloudflare can easily work as a HTTPS frontend on port 443 for an origin web service without HTTPS on port 80. The question is simply, how can I accomplish this for another service on the same host.

Wow. There are still some web services provided without HTTPS. @sandro leave some comments please.

1 Like

Please believe me, the last person you want to comment on this is me :smile:

2 Likes

I need to as well; thank-you @sandro .

Why in the name of all things good would anyone even use an unsecured endpoint? Not me.

Yep, I think once someone said if you can’t say anything nice, don’t say anything at all and I will stick to this at this point as we otherwise will have yet another 500-replies thread :wink:

And, sorry, but Cloudflare is not completely innocent on this either as they make that possible in the first place and by that the Internet less secure as a whole.

2 Likes

Indeed. I fully understand the risks and limitations related to the matter. Apologies, but I also don’t feel it’s very productive to spend several messages meditating on the matter. I fully understand that I as the customer am a complete idiot here. The question is simply whether Cloudflare has the capabilities to still support in this specific use case, as they do in other similar cases.

To repeat my earlier message, Cloudflare can easily work as a HTTPS frontend on port 443 for an origin web service without HTTPS on port 80. The question is simply, how can I accomplish this for another service on the same host.

It can and that has been a horrible decision ever since someone at Cloudflare thought it would be a good idea to front insecure sites and then still pretend to do something for the security of the Internet.

But, just because you can do it does not mean you should do it and, at least, my stance is pretty clear here. Sorry that I cannot and will not say anything more but I won’t be an accessory to such a setup in any way.

The best (and most reasonable) advice I can give, set up a local reverse proxy which accepts SSL and then proxies on to your HTTP server. That will be secure and you won’t have to touch the legacy setup.

Then why even comment on the thread? When you don’t have any of the facts related to the risks and whether they are being managed in other ways?

Maybe because I was tagged twice? Maybe because this is a community and not your personal support channel?

I addressed all of that earlier and even provided a reasonable approach to your problem.

As what @cscharff mentioned, port 8443 is a HTTPS port. And Cloudflare will not contact your origin server in HTTP in this case.

A workaround might be writing your own Workers script and “proxy” all traffic coming to port 8443 via HTTPS to your server port 8443 via HTTP - if you are okay with the possibility that someone may do a MITM between Cloudflare and your server.

1 Like

And TLS1.0 & 1.1 are still not only present in the dash, they are the defaults. TLS1.0 is default. Sorry but if there’s someone stuck using Windows CE or w/e then it’s time to use Linux.

Oh so much more than that :smirk:

1 Like

He was tagged in by others because of his somewhat militant but not incorrect stance.

If you have a private interconnect with Cloudflare then it would probably have been worth mentioning, otherwise the traffic is transiting the public internet in plain text so Sandro’s point is valid regardless of any attempt at risk mitigation in other areas.

It’s an off topic point and trivial to change for your own config to whatever minimum version you prefer.

Use a different hostname and either use Workers to modify the calls to http on a different port or use Argo tunnels.

Agreed, though this is a different story. TLS 1.0 provides proper encryption, it has security vulnerabilites, but that’s a different issue. Flexible is a whole different world and if you take a second and think about it, it is a security nightmare. I still cannot comprehend how anybody signed that off, unless there was huge pressure from the marketing department.

@cscharff once mentioned one use-case but even there a “simple” local proxy would fix the issue. IMHO there is no excuse for that security “feature” but yeah, we have been on that topic more than once :slight_smile:

That has a rather negative connotation but yes, when it comes to security I do not really fancy a compromise. If you compromise there, you literally will be compromised.

Almost forgot about this, yeah. Another good use case.

Plus, these things really are easy to fix, so all these discussions are truly pointless and only exist because people couldn’t care less to take the five minutes to set up a certificate or hire someone to do it, if they don’t have the expertise and don’t want to acquire the knowledge.

Even the one use-case you mentioned months ago can be addressed with a local HTTPS-to-HTTP proxy.

I am afraid to this date I am yet to hear a use-case where Flexible would be reasonably really the only solution.