0

So here's the setup. I've got a Rails 3 application deployed to two servers, both running Apache2, both with identical VirtualHost configs, both operating on Passenger. There are a few routes in the Rails application that require requests to be done on SSL, so I've defined those routes with :protocol => 'https as necessary.

These two servers are part of a load-balancing pool on our BigIP load balancer, with one profile setup to handle port 80 traffic, and another to handle port 443 traffic. We've purchased a cert and we've loaded it onto the BigIP box, as well as setup a profile for the cert that's assigned to the :443 profile.

My Apache configs on each server identically define ServerName, DocumentRoot, SetEnv (for my Rails environment), and all that jazz inside a <VirtualHost *:80 *:443> declaration (note that in mucking with these files, removing the *:443 bit changed absolutely nothing). There's nothing really out of the ordinary there.

When browsing to this site on port 80, traffic passes through just fine and it hits the Rails application. When browsing to the login page, which requires HTTPS, the browser will just sit there and try to contact the page. Eventually my browser gives me a server unexpectedly dropped the connection error.

My question is this: how does BigIP send SSL traffic to the servers in its pool, and how is Apache supposed to recognize that? I don't even get entries in my Apache logs that the traffic even hits the two backend servers. Is there something I need to modify with a Passenger configuration somewhere to allow this traffic?

If there's more info needed than what I've posted already, let me know and I'll append it to this question. It appears I'm greener at this kind of stuff than I thought!

Also; since I feel really kinda dumb about this stuff, what's a great resource to help me learn about how web servers handle SSL requests?

Ben Kreeger
  • 113
  • 5

2 Answers2

1

If you've loaded the certs on the F5 LTM and associated them with the virtual server listening on port 443 then the the F5 terminates the SSL and passes the HTTP traffic to the pool. Apache won't see SSL traffic, just the "http" part of https. You can use the same pool as the port 80 traffic.

It sounds like either your cert isn't loaded properly in the F5 or the ssl profile is not associated with your 443 Virtual Server.

ERR0
  • 158
  • 5
  • I'll double-check it all, but I know the certs were loaded into our F5 (not sure about *properly*, but they're there), they were associated with an SSL profile, and that specific profile was associated with our 443 virtual server's profile. Both virtual servers (80/443) are running out of the same pool. – Ben Kreeger Jul 27 '11 at 20:05
  • It's looking more and more likely that our cert wasn't loaded in correctly. Somebody else (other than the typical guy that handles our F5) loaded in the cert, and he did it differently… we're not sure, but that puts us down a more certain path. Thanks for your answer, @ERR0! – Ben Kreeger Jul 27 '11 at 21:58
  • what port are you sending your 443 virtual server traffic to in your pool? – ERR0 Jul 28 '11 at 16:23
1

My answer is similar to ERR0's...

If you have private VLANs then it's really not necessary for your HTTP server to listen on 443. Rather your application should be reverse proxy aware and redirect certain pages e.g. /login to a SSL/HTTPS version of the page.

Read up on the X-Forwarded-For and X-Forwarded-Proto HTTP Headers.

I'm not familiar with Rails but perhaps there is a module that does this for you? i.e. Allows you to specify which pages should redirect to a SSL/HTTPS version.

Cheers

HTTP500
  • 4,827
  • 4
  • 22
  • 31
  • In Rails, ensuring certain pages route to an SSL version can happen in the `routes.rb` file; just specify that the protocol must be HTTPS, and the redirection will happen. Rails also handles the necessary redirection headers. — Our VLANs are indeed private, so I've set our Apache web servers to listen on port 80 and not 443. The requests still don't seem to make it past our F5, though. – Ben Kreeger Jul 27 '11 at 20:03
  • I'd double-check that the HTTPS profile on the F5 is terminating to port 80 on your backend server. Also, if you have access to the logs on the F5 check there to see if they give a clue. – HTTP500 Jul 27 '11 at 20:17
  • Thanks, @jasondbecker; what's the easiest way to check that the profile on the F5 is terminating correctly? – Ben Kreeger Jul 27 '11 at 21:51