Chapter 11: Switching Secured Content

Cisco Press

1 2 3 4 Page 2
Page 2 of 4

Configuring URL and Header Rewrite on the CSS

You learned previously that, without back-end encryption, real servers receive cleartext requests and send HTML page responses in cleartext (in Steps 6–8 from Figure 11-1). However, if an HTML page includes embedded HTML references to other sites, you need to make sure that these links are prefixed by "https://" and not "http://"; otherwise, your browser may give you an error while accessing the secure site.

For example, your HTML page may include the following links:

<A HREF="http://cisco.com/support.html">Support</A>

<A HREF="http://cisco.com/services.html">Services</A>

<A HREF="http://cisco.com/products.html">Products</A>

To inform your HTTP server that the current cleartext request is from the CSS SSL module (in Step 6) and is not a client request, you can configure the CSS SSL module to add an HTTP header to the HTTP request. For example, you can add an HTTP header including the SSL session information. To enable the CSS to insert SSL session information HTTP headers into requests that it proxies, use the following proxy list mode command, as Example 11-2 illustrates:

ssl-server number http-header session

You can then configure your HTTP servers to recognize these headers and supply an HTML page containing "https://" within the embedded links instead of "http:// ."


Note - You can also configure the CSS to insert the client and server certificates as HTTP headers using the client-cert and server-cert keywords of the ssl-server http-header proxy list command.


Additionally, if your servers send HTTP 300 series redirects to your clients, then you should configure your CSS to rewrite the "http://" reference in the "Location:" header of HTTP 300 series redirect methods to "https://" with the proxy list command:

ssl-server number urlrewrite number hostname [sslport port {clearport port}]

This command enables you to specify particular URLs that you want to rewrite in HTTP 300 series redirects, by including the exact URL or by using wildcards. Entries without wildcards take precedence over wildcard entries, and prefix wildcards entries take precedence over suffix wildcard entries. For example, you can configure your CSS to rewrite all redirects for "*.cisco.com" (prefix wildcard) and "http://www.cisco.*" (suffix wildcard) with the commands:

ssl-server 1 urlrewrite 1 *.cisco.com
ssl-server 1 urlrewrite 1 http://www.cisco.*

You can also rewrite nonstandard cleartext HTTP ports (that is, any port other than port 80) with either the standard SSL port (that is, port 443) or nonstandard SSL ports. For example, the following command will rewrite "http://www.cisco.com:81" to "https://http://www.cisco.com":

ssl-server 1 urlrewrite 1 http://www.cisco.com clearport 81

The following command rewrites "http://www.cisco.com" to "https://http://www.cisco.com:444":

ssl-server 1 urlrewrite 1 http://www.cisco.com sslport 444

The following command rewrites "http://www.cisco.com:81" to "https://http://www.cisco.com:444":

ssl-server 1 urlrewrite 1 http://www.cisco.com sslport 444 clearport 81

Note - Neither the CSM nor CSS supports rewriting HTTP URLs embedded directly within HTML pages.


Configuring Your Content Services Module with SSL

You can also configure your CSM-S for SSL termination. As with the CSS with an SSL module, you can import existing keys and server certificates to your CSM-S daughter card or generate new keys and request server certificates from a CA.


Note - You can also configure SSL termination with the CSM using a separate SSL services module (SSLM). The configuration for the SSLM is the same as the CSM-S. For more information on the SSLM, refer to its product documentation on Cisco.com.


Creating and Importing Keys and Certificates on the CSM

To generate a private/public key pair on your CSM-S daughter card, use the command:

crypto key generate rsa general-keys label key-label [exportable] [modulus size]

For example, the crypto key generate command produces the output in Example 11-3 to generate a key pair called mycontentkey on the CSM-S. If you want to be able to export the private key from the SSL daughter card for future use outside the CSM-S, you can use the exportable keyword.

Example 11-3 Configuring Your CSM to Generate an RSA Key Pair

ssl-card(config)# crypto key generate rsa general-keys label mycontentkey exportable
The name for the keys will be: mycontentkey
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]: 1024
Generating RSA keys.... [OK].

To enter your organization's information for a CSR, you must create a trust point, as Example 11-4 illustrates.

Example 11-4 Configuring a Trust Point on the CSM-S

crypto ca trustpoint mycontent-trustpoint
 rsakeypair mycontentkey
 serial 
 subject-name C=US, ST=California, CN=http://www.cisco.com, OU=Network Engineering, O=Cisco Systems, Inc.
 enrollment url tftp://10.1.1.1/certificates

To generate a CSR for the key pair, use the command:

crypto ca enroll trustpoint-name

For example, Example 11-5 shows the command output to generate a request for the key pair mycontentkey that Example 11-3 previously generated.

Example 11-5 Creating a CSR on Your CSM-S

ssl-card(config)# crypto ca enroll mycontent-trustpoint
% Start certificate enrollment .. 

% The subject name in the certificate will be:CN=http://www.cisco.com, OU=Network Engineering, O=Cisco Systems, Inc.
% The fully-qualified domain name in the certificate will be:http://www.cisco.com
% The subject name in the certificate will be:http://www.cisco.com
% The serial number in the certificate will be:B0FFF22E
% Include an IP address in the subject name? [no]:no
Display Certificate Request to terminal? [yes/no]:yes
Certificate Request follows:

MIctCMtmZONOY+ybEHl/mX0RdqXFnivLBgNVBAYTAlVTMRAwDgYDVQQIEwdHZW9y
DQ kW6Pa6mbjeUV1wffn2dtbKsmz7DnK2BVbml2ZXJzaXR5IG9 yRPs36ywGwDK3
aWExNTAzBgNVBAsTLFVuaXZlcnNpdHkgQ29tcHV0aW5nIGFuZCBOZXR3b3JraW5n
IFNlcnZpY2VzMRYwFAYDVQQDEw13d3ctcy51Z2EuZWR1MIGdMA0GCSqGSIb3DQEB
AQUAA4GLADCBhwKBgQDh3yRPs36ywGwDK3ZS3qaOoNraOFHkSNTsielHUMHxV1/G
N1E43/bifEQJUvSw/nrkOQf3Ync8O/39lelUTJeP6QZkX9Hg1XtuSUov3ExzT53l
vbctCMtmZONOY+ybEHl/mX0RdqXFnivLpXohr7dJ5A1qHfjww/SLW8J/7UXj1QIB
A6AAMA0GCSqGSIb3DQEBBAUAA4GBAIEu35zoGmODCcwwNrTqZk3JQAjyONJxjjtd
uQ+QLQcckO4aghBpcqsgLckW6Pa6mbjeUV1wffn2dtbKsmz7DnK2fwnyaBtxXMvi
CC4o9uvW11i5TjdorfOdRI1lR0FrNAzf+3GQUl1S2a83wagvFjo12yUCukrxBgyU
bXbmNuJpkdsjdkjfkdjfkdfjdkfjdkfjdkfj

---End - This line not part of the certificate request---

Redisplay enrollment request? [yes/no]:no

As you learned previously, to apply for a server certificate, you must send the CSR to a public CA of your choice (such as Verisign), or to your own private CA (such as Microsoft Certificate Services). If you use a public CA, once you receive the server certificate, you can TFTP it to the CSM-S using the crypto ca import command, as Example 11-6 illustrates. The CSM-S connects to the TFTP server specified previously in Example 11-4 using the enrollment url command. Make sure your certificate exists on a valid TFTP server before using the crypto ca import command.

Alternately, if you use a private CA, you can specify its URL with the enrollment url command, and the crypto ca import command will connect to the private CA to download the server certificate.

Example 11-6 Importing a Server Certificate on Your CSM-S

ssl-card(config)# crypto ca import mycontent-trustpoint certificate
% The fully-qualified domain name in the certificate will be: ssl-card.cisco.com
Retrieve Certificate from tftp server? [yes/no]:yes
% Request to retrieve Certificate queued

ssl-proxy(config)#
Loading mycontent-trustpoint.crt from 10.1.1.1 (via Ethernet0/0.172):!
[OK - 1608 bytes]

ssl-proxy(config)#
*Nov 25 21:52:36.299:%CRYPTO-6-CERTRET:Certificate received from Certificate Authority
ssl-proxy(config)# ^Z

Note - Make sure you load your CA's certificate (and intermediate certificate, if necessary) to the CSM-S using the crypto ca authenticate command. Also use the enrollment url command to make sure that the CA's certificate resides on the TFTP server you specify. If you are using your own private CA, the crypto ca authenticate command will load the CA certificate from the private CA.


Alternately, if you have existing private keys and certificates, you can import them into your SSL daughter card. For example, to import an existing PKCS#12 key, you need to have previously generated the PKCS#12 file using an external PKI system. Recall from Chapter 8 that a PKCS#12 file can contain a private key and server certificate chain.

Then, to import the existing private key and server certificate chain from the PKCS#12 file to your CSM-S, you can use the following command:

crypto ca import trustpoint_label pkcs12 {scp: | ftp: | nvram: | rcp: | tftp:} [pkcs12_filename] pass_phrase

Note - Using the crypt ca import command to import PKCS#12 certificates automatically generates the trust point configuration for use in your SSL proxy services. You will learn how to configure a proxy service on the SSL daughter card later in this section.


Terminating SSL on the CSM-S

Now that you have private keys and server certificates on your SSL daughter card, you can configure your CSM-S to terminate SSL connections. You can configure the content switch either in NAT-mode (that is, the content switch will destination-NAT the client's request to the SSL daughter card's IP address in Step 2 from Figure 11-1) or in dispatch mode (that is, the content switch will route the packet directly to the SSL daughter card without DNATing it). If you configure the content switch in NAT-mode, make sure you configure the SSL daughter card to DNAT the packet back to the virtual server IP address. Example 11-7 shows how to configure your CSM to terminate SSL connections in dispatch-mode, based on the network topology in Figure 11-2. For the example in this section, the SSL daughter card farm is in bridge-mode and the real server farm is in router-mode, as Figure 11-2 illustrates.

Figure 11.2

Figure 11-2

Dispatch-Mode CSM with SSL Daughter Card in Bridge-Mode

Example 11-7 Configuring Your CSM to Terminate SSL in Bridge-Mode

interface vlan 10
 description *** Client VLAN
 ip address 10.1.10.2


interface fastethernet 2/1
 description *** Web01
 switchport vlan 30

interface fastethernet 2/2
 description *** Web02
 switchport vlan 30

ip route 10.1.30.0 255.255.255.0 10.1.10.1
ip route 10.1.99.0 255.255.255.0 10.1.10.1
module csm 5 

vlan 10 client
 ip address 10.1.10.1 255.255.255.0
 gateway 10.1.10.2

 vlan 20 server
 ip address 10.1.10.1 255.255.255.0

vlan 30 server
 ip address 10.1.30.1 255.255.255.0

vlan 99 server
 ip address 10.1.99.1 255.255.255.0

serverfarm ssl-accel-farm
 no nat server
 no nat client
 real 10.1.10.10 local
 inservice

serverfarm webfarm
 nat server
 no nat client
 real 10.1.30.10
 inservice
 real 10.1.30.11
 inservice

serverfarm forward-route
 no nat server
 no nat client
 predictor forward

vserver https-vip
 virtual 10.1.10.100 tcp https
 vlan 10
 serverfarm ssl-accel-farm
inservice

vserver http-vip
 virtual 10.1.10.100 tcp www
 serverfarm webfarm
 persistent rebalance
 inservice

vserver direct-web
 virtual 10.1.30.0 255.255.255.0 any
 serverfarm forward-route
 inservice

vserver direct-ssl
 virtual 10.1.99.0 255.255.255.0 any
 serverfarm forward-route
 inservice

Here are some notes to help you understand the configuration in Example 11-7.

  • Recall from Chapter 10 that configuring bridge-mode requires that you give the client VLAN 10 and server VLAN 20 interfaces the same IP address (that is, 10.1.10.1 in Example 11-7).

  • Use the no nat server command to prevent the CSM from DNATing client requests to the SSL daughter card (thus enabling dispatch-mode processing).

  • The virtual server "http-vip" serves traffic from both cleartext client requests and from unencrypted traffic forwarded by the SSL daughter card.

  • The command vlan 10 within the "https-vip" virtual server configuration indicates that the virtual server shall receive traffic from only VLAN 10.

  • You need to include the local keyword when configuring the SSL daughter card as a real server within a server farm. This keyword indicates to the CSM that the real server is the SSL daughter card and not an external real server.

  • The "direct-type" virtual server is necessary for you to be able to directly connect to your secure router-mode real servers for testing purposes. You also need to add a static route to the MSFC pointing to the CSM client IP address for the subnet of the router-mode reals (for example, ip route 10.1.30.0 255.255.255.0 10.1.10.1, in Example 11-7).

  • VLAN 99 is for administering the SSL daughter card using Telnet.

  • Because the SSL devices preserve the source IP address of the packet as the client's IP address, the CSM-S must use special routing for real-server return traffic. If the CSM-S uses normal routing, the cleartext real server return packets are routed to the client directly, bypassing the SSL daughter card. Therefore, the CSM-S routes the back-end real server return packets to the SSL daughter card by tracking the Layer 2 MAC address of the SSL daughter card during the connection flow.

Example 11-8 gives the corresponding SSL daughter card configuration for CSM-S termination. Whereas with the CSM-S you did not have to directly configure the SSL module with IP addressing, you must configure the CSM-S daughter card with an IP address and default gateway. The SSL daughter card is a separate TCP/IP host on the network and, as such, it responds to ARP requests. You must also administer it separately via Telnet through a separate command line interface.

Example 11-8 Configuring Your SSL Daughter Card for SSL Termination

Related:
1 2 3 4 Page 2
Page 2 of 4
SD-WAN buyers guide: Key questions to ask vendors (and yourself)