Take the 2-minute tour ×

We have a Cisco CSM-S content switch with SSL. Currently our website is behind this switch, which performs load balancing for the HTTP and SSL sites. The http and https sites use different hostnames

        http://www.site.com=>*   *==>Main servers
                             * C *   
                             * S *   
                             * M *
    https://secure.site.com=>*   *==>Ecom servers

The SSL traffic is decrypted by the SSL daughter-card in the CSM, and traffic is then routed by URL to the various servers based on the HTTP hostname. I'd like to add HTTPS support to the main site for non-ecom secure pages but my admin says the CSM isn't capable of routing the traffic in this way. Here is my planned config:

         http://www.site.com=>*   *=(http)=>Main servers
        https://www.site.com=>* C *   
                              * S *   
                              * M *
     https://secure.site.com=>*   *=(http)=>Ecom servers (secure network)

The way I understand it, the SSL daughtercard should be operating at a layer beneath the HTTP routing, and thus the fact that the main site's secure and non-secure pages all go to the same internal servers should allow this configuration to work.

Does anyone know if the CSM-S supports this configuration? And if it does, how can I describe to my admin how it needs to be set up?

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

If www.site.com and secure.site.com resolve to different IP addresses, I don't see how this could be a problem. We have a non-SSL CSM and do this today. The main extras that the CSM-S get you are visibility into SSL packets for load balancing purposes and hardware SSL termination.

If the sites resolve to the same IP address, then your admin is right that it will be a problem. It wouldn't be any different from trying to host these two distinct SSL sites on a single Web server without the CSM-S present. With HTTPS, the server has to negotiate SSL before the client has a chance to tell the server which site it wants. If you have a regular single-host certificate, and the server (or CSM-S) has to talk SSL for multiple sites on a single IP, it will have no way of knowing which certificate to present to the client.

There are three ways that I know of to support multiple name-based SSL sites on a single IP:

  1. Use a wildcard cert. For this to work, all sites must be in the same domain.
  2. Use a Subject Alternative Name (SAN) cert, sometimes called a UCC or Unified Communications Certificate because Microsoft OCS apparently tends to use multiple hostnames. The only real restriction here is that most issuers will limit the number of sites per certificate.
  3. Use Server Name Indication (SNI) on your servers, which lets the client request the site name during TLS negotiation. It is supported on very recent versions of Apache, though client support is mixed. However, I don't think the CSM-S supports SNI, so if you're doing SSL termination on your CSM-S, then it won't be an option for you anyway.

If you aren't already doing so, running www.site.com and secure.site.com on different IP addresses will probably be the easiest thing for you to do. If the CSM-S can load balance based on Host: header and not just ip:port, then changing to a SAN or wildcard cert shared by both sites is another option.

share|improve this answer
add comment

James posted while I was typing...way to steal my thunder =)

I would add to James comments tho:

  1. if the sites resolve to the same IP address externally, this is not necessarily a problem, as you can configure a policy to check the host header.
  2. If it is the same server(s) on the backend, this is still doable either with a wildcard cert as James mentions, or by running the servers on different ports and specifying those ports in different serverfarms (effectively treating them as entirely different servers).


vserver FOOBAR 
 ip address any


vserver FOOBAR
 ip address tcp  www


vserver FOOBAR_S
 ip address tcp https
share|improve this answer
You can't check the Host header because the client doesn't send it until after SSL negotiation, and the CSM-S (or server) won't know which SSL certificate to present without the Host header. The backend isn't nearly as important, because you can run the sites on separate ports without the client knowing (or caring), as you pointed out. Since Mr. New and Shiny appears to be doing SSL termination on the CSM-S, the internal Web servers may not even be aware that SSL is in use. –  James Sneeringer Sep 21 '09 at 18:19
Unless the CSM-S is radically different than the plain CSM, the https version of the main site is still nothing more than another virtual. Unless you're running raw virtuals without port/service definitions, in which case I could see that you'd need to replace those with virtuals where you define the ports. If you're running bare real definitions, that should be fine, as the virtual will pass thru the requested port. Editing my answer to give an example... –  Greeblesnort Sep 23 '09 at 4:38
add comment

Your Answer


