Two basic questions here:
If I want to serve SSL content from 3 different servers (A, B, C) through a reverse proxy (P), where does the SSL magic happen?
I'm guessing that each server will be responsible for handling the SSL stuff and X just routes the bits, but I'm not sure. Presumably in this case, I would use the same cert signed for X on each machine A, B, C. Or does X do all the SSL stuff by itself?
Second, what's the best webserver to use for the reverse proxy on Windows Server 2008? IIS, Apache, etc. Extra credit if you have a good example of setting one up with your recommendation.
Thanks for your help!
I assume by "Reverse Proxy" you mean an Apahce server acting as a Proxy vs. DNAT (Destination NAT). In this case, your clients see your servers (A,B,C) with internal IPs (IA,IB,IC) as external or public IP devices (XA, XB, XC).
If, on the other hand, you want to represent your (IA, IB,IC) devices as a single external IP (XIP) then you will need to use SSL Certificates that incorporate multiple subject alternate names. In fact, if you have only one public IP and you want multiple SSL sites against that one public IP, you will need to use a cert with multiple subject alternate names regardless of the reverse proxy going on. The attribute is called "SubjAltName" in X.500 land.
This link may help you: http://www.wlug.org.nz/ApacheReverseProxy
You really can't DNAT HTTPS connections unless your DNAT knows how to handle SSL Certs - you're basically creating a MITM (man-in-the-middle) process; one of the very things SSL tries to protect against.
I quote from our excellent CMS support guy
"The thing that needs to be thought about for this is where you will do the SSL termination
In other words will the request be client to proxy as https and then http from the proxy to the internal box where you are getting apache to terminate the SSL
Or
The entire conversation is SSL
I would favour the 1st option where you let Apache terminate the SSL as there is no real need to have the entire conversation as https
I would put the certificate on the apache server within a virtual host directive and then proxy that request on to the internal box."
In other words either, but it's easier to avoid encrypting internally on your own network.
IIS won't reverse proxy as far as I know (certainly up to IIS 6, not sure about later), so its Apache. You can also use SQUID which seems to be good, although I have no direct experience of it.
See also my question on StackOverflow (https://stackoverflow.com/questions/283636/apache-reverse-proxy-set-up-ssl-certificate) concerning the correct config for Apache.
You can set up a Microsoft ISA server as your reverse proxy for your SSL. This then forwards the traffic over port 80 to IIS residing on another server. This will also work for wildcard certs in case you were wanting to use them. I believe you can use this to do load balancing also.