Home / server / Questions / 67295
Accepted
Mr. Shiny and New 安宇
Asked: 2009-09-22 05:12:25 +0800 CST

Cisco CSM-S (with SSL) secure and non-secure service for the same IP/hostname?

  • 772

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?

ssl

2 Answers

  1. Best Answer

    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.

    • 1

  2. 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).

    Example:

    vserver FOOBAR 
 ip address 1.2.3.4 any

    versus

    vserver FOOBAR
 ip address 1.2.3.4 tcp  www

    plus

    vserver FOOBAR_S
 ip address 1.2.3.4 tcp https
    • 0