Secure Web Servers SSL and certificates

[Jim Edison]

Hi All, (this is lengthy, my apologies)

In another post regarding using a proxy service to redirect to an internal web server requiring https/ssl it was noted "WinGate doesn't make an SSL connection inbound in this case. It will accept the connection with SSL, but won't make an SSL connection to your internal server." Solution was to open port 443 in Enhanced Network driver and redirect to my internal server and this works great.

This caused me to rethink how I might handle https/ssl connections and the necessary certificates. Currently I simply install the certificate on the internal server and have the server require an SSL connection on port 443. - Simple and this works

I am now thinking it might be better to handle the secure site certificate and SSL connection at Wingate and then proxy the connection on a non-ssl connection to my internal server and not require the server to run https, assuming first, this would be a workable solution and Wingate will handle the SSL connection properly with the users browser.

Any input into experiences, recommendations, sources of info would be appreciated.

[logan]

As for experiences or recommendations, I haven't set up a scenario like this before and therfore have no experience or recommendations that I can pass on, but here are a couple of points about using WinGate's SSL handling capability to do the SSL side of things on WinGate's end, instead of the web server end.

• To do anything advanced with SSL in WinGate, you will need an Enterprise license so that SSL binding support for services is enabled. If you currently have either a standard or pro license, then you will need to factor in the cost of upgrading to enterprise.
  (ref. http://www.qbik.com/products/wingate/licensing.php )
  
  
• It's important to ask what you are expecting to get out of doing SSL in WinGate on the edge of the network that you wouldn't get out of doing SSL at the server itself, and is it possible that doing this might be alot of effort for little or no gain?
  
  The only scenario I can think of that would require this sort of configuration is if you have multiple webservers on the local network that all want to use port 443. If this is the case, WinGate can do the dirty work of decrypting SSL, and then read the incoming packets, forwarding them to their respective servers. All is well and good.
  
  However, other than the above scenario, I can't think of any other advantages that having WinGate do SSL instead of the web server will have. In fact having WinGate do SSL sounds like more of a disadvantage since you will end up restricting yourself to a single certificate for all the virtual hosts you might set up on your web server.

If you decide to go ahead with this, you can contact me using skype. I'd be happy to give you a hand setting this up.

[logan]

I just read your other post and have a better idea of what you are trying to acheive now :). Using WinGate to do SSL may or may not work, so give me a yell on skype and we can talk about/try it.

[boblowski]

I am now thinking it might be better to handle the secure site certificate and SSL connection at Wingate and then proxy the connection on a non-ssl connection to my internal server and not require the server to run https, assuming first, this would be a workable solution and Wingate will handle the SSL connection properly with the users browser.

That is exactly what we do, and we are very happy with this setup. WinGate takes care of the SSL part for outside connections, and uses non-SSL connections to our internal servers. We use a wildcard certificate for the SSL, so we can present every internal server as a subdomain of our actual domain. (Which has the added benefit that you don't have to worry about things like url rewriting.)

If you bring the SSL wrapping to the proxy server, you can freely replace and switch your backend servers without breaking the SSL chain. Some reverse proxy solutions (and perhaps WinGate 2009 as well?) use this for load balancing and fail over.

The only problem with this setup, is that many webapps look at the incoming port or used protocol to decide how they will generate url's. Chances are, your webapp only sees a normal non-SSL connection and thus serves http links. You can solve this in the application itself (most php applications start with setting a parameter which tells the app whether to generate https or http links), with a Apache rewrite directive, or by telling WinGate to redirect every http request to the https url. Plain websites normally don't need anything special and just work like always.