Cisco ACE XML Gateway User Guide (Software Version 6.1)
Securing Traffic with SSL/TLS

Table Of Contents

Securing Traffic with SSL/TLS

About SSL/TLS Traffic Encryption

Securing the Service Consumer Connection

Securing the Service Provider Connection


Securing Traffic with SSL/TLS


This chapter describes how to use SSL/TLS to secure service traffic. It covers these topics:

About SSL/TLS Traffic Encryption

Securing the Service Consumer Connection

Securing the Service Provider Connection

About SSL/TLS Traffic Encryption

The Secure Sockets Layer (SSL) and subsequent standardization of SSL, Transport Layer Security (TLS), are a widely used method of securing network traffic. You can use SSL with the ACE XML Gateway to secure communication between the ACE XML Gateway and service consumer or between the ACE XML Gateway and backend service provider.

To use SSL with consumer connections, you need to upload and specify a public/private keypair to be used to establish the SSL session. For information on loading keypairs, see "Uploading a Keypair Resource" section on page 28-285

Note that SSL is used in the system for purposes other than securing service traffic as well. The ACE XML Manager serves the web console over SSL, for instance. Also, log and administration information is passed between the ACE XML Gateway and Manager by SSL. Therefore, there are several areas in the web console for configuring SSL certificates. This chapter describes how to set up the ACE XML Gateway to use SSL specifically for service traffic.

Securing the Service Consumer Connection

To use SSL for the consumer connection, the ACE XML Gateway needs to have a public/private keypair. The keypair can be either a self-signed certificate or one signed by a Certificate Authority. A self-signed certificate is normally sufficient if the consumer is internal to your organization. For other purposes, you should use a CA-signed certificate.

For compatibility with certain types of clients, a certificate used for a port at the ACE XML Gateway (as described here) may need to be configured as a server certificate. That is, the certificate needs to have an X509v3 Extended Key Usage attribute of TLS Web Server authentication. This is only a potential requirement for certain clients, however; the ACE XML Gateway system does not require you to use server certificates and non-server certificates may work in many instances.

To configure an encrypted channel between the ACE XML Gateway and consumers:


Step 1 Click the HTTP Ports & Hostnames link in the navigation menu.

Step 2 If the port on which you want to configure SSL connections already exists, click the edit link for that port. If the port does not exist, open the port as described in Chapter 15, "Working with Ports and Hostnames."

Conventionally, port number 443 is used for SSL. However, you can use any port number you like, including port 80, the default port number for non-secured HTTP communication.

Step 3 In the Edit Port page, click the SSL check box. When this option is selected, SSL encryption is used for communication on that port.

Step 4 In the Public/Private Keypairs menu, choose the keypair you want to use for the connection.

If the keypair you want to use is not already uploaded in the ACE XML Manager, follow the directions in "Uploading a Keypair Resource" section on page 28-285 to upload the keypair.

Step 5 During SSL connection setup, the ACE XML Gateway and client negotiate various parameters of the connection, including the SSL Cipher Suite to be used for message encryption or authentication. By default, the ACE XML Gateway is not selective about the cipher suite it will accept on a port. It will accept most encryption algorithms, including those using 64 or 56 bit keys.

Specifically, the default Cipher Suite list it uses is: ALL:!ADH:!EXPORT:!SSLv2:!LOW:+HIGH:+MEDIUM

You can limit the cipher suites that are accepted by the ACE XML Gateway on the port by choosing custom from the SSL Cipher Suite menu. In the text field that appears, enter the set of cipher suites to be permitted in standard OpenSSL Cipher string format, as described here: http://www.openssl.org/docs/apps/ciphers.html

For example, to permit only algorithms that use keys that have a length of 128 bits or greater and not anonymous DH, use:

HIGH:MEDIUM:!ADH

This is equivalent to specifying:

DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA :EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA: DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA: DHE-DSS-AES128-SHA:AES128-SHA:DHE-DSS-RC4-SHA: KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA:RC4-MD5: RC2-CBC-MD5:RC4-MD5:KRB5-DES-CBC3-MD5: KRB5-DES-CBC3-SHA

If the client is not capable of using any of the SSL Cipher Suites specified, the connection is not permitted. The event log will show a warning level event similar to: "Terminating HTTP session: 400 Bad request."


Note Use care when entering the cipher suite string. The ACE XML Manager interface does not verify the value you enter. If you mistype or enter a meaningless value, the port will be unusable.


Step 6 Click Save Changes to finish the port configuration.


Now you can configure the virtual web application or virtual service object to use the port. For example, for a virtual web application, perform these steps:


Step 1 Click Virtual Web Applications on the navigation menu.

Step 2 Select the basic virtual service object or handler for the service for which you would like to secure traffic.

Step 3 Click Edit next to the Consumer Interface heading of the properties page for the virtual service.

Step 4 For the Port value, choose the port you just configured for SSL from the list.

Step 5 Click Save Changes to commit the changes to the active subpolicy.


This completes the client side SSL configuration. Deploy the policy to have the changes take effect at the Gateway.

Securing the Service Provider Connection

You can configure SSL encryption for connections between the ACE XML Gateway and backend service providers.

To secure the backend server connection, you'll need to have the appropriate security resource for verifying the server certificate, either a remote server certificate or the certificate of the trusted CA used by the remote server. To specify trust for a CA, you need to import its certificate in the policy. By default, the policy contains no preloaded CA certificates.

Note that the ACE XML Gateway also supports bilateral SSL, in which the ACE XML Gateway authenticates itself to the backend system. To use bilateral SSL, you'll need to have the ACE XML Gateway's public/private keypair loaded to the ACE XML Manager.

To configure bilateral SSL:


Step 1 Click the Destination HTTP Servers link in the navigation menu.

Step 2 If the server for which you want to configure SSL already exists, click the view link for that server.

If the server does not appear in the server list, click the Add a New Server button and configure the backend server as described in "Adding a Destination HTTP Server" section on page 14-146.

Step 3 In the Edit Server page, click the Edit link next to the general settings heading.

Step 4 To have communication with the server occur over an SSL channel, enable the SSL option.

The controls for configuring the SSL channel are enabled.

Step 5 In bilateral SSL, the server asks clients (the ACE XML Gateway, in this case) to authenticate itself as part of the SSL negotiation. If it does, you can specify the client public/private keypair to use from the If requested, use client public/private keypair menu.

Step 6 Specify how the ACE XML Gateway should verify certificates that the server presents:

To accept any certificate the web service presents, leave the Require remote server certificate signed by this CA certificate option at its default value, none. This setting is the default. The ACE XML Gateway will accept any certificate the server presents.

To accept any certificate that a specified Certificate Authority (CA) has signed, with the Require remote server certificate signed by this CA certificate option selected, choose one or more CA's listed in the menu. If the certificate does not appear in the menu, choose Upload and add the certificate to the ACE XML Manager's list of Trusted Certificate Authorities.

To accept a certificate identical to a particular certificate, click Require a certificate from the remote server that is identical to this certificate and choose the certificate from the menu. If the certificate does not appear in the menu, choose Upload and add the certificate to the ACE XML Manager's list of remote server certificates.

Step 7 During SSL connection setup, the ACE XML Gateway and backend server negotiate various parameters of the connection, including which SSL Cipher Suite to use for message encryption or authentication. By default, the ACE XML Gateway is not selective about which cipher suite it will accept. It will accept most encryption algorithms, including those using 64- or 56-bit keys.

You can limit the cipher suites that the ACE XML Gateway will accept in establishing the connection to the backend server by choosing custom in the SSL Cipher Suite menu. In the text field that appears, enter the cipher suites to use for the server connection in standard OpenSSL Cipher string format, as described here: http://www.openssl.org/docs/apps/ciphers.html

For example, to permit only algorithms that only keys that have a length of 128 bits or greater and not anonymous DH, enter the following in the text field:

HIGH:MEDIUM:!ADH

This is equivalent to specifying the following:

DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA: DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA: DHE-DSS-AES128-SHA:AES128-SHA:DHE-DSS-RC4-SHA: KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA:RC4-MD5: RC2-CBC-MD5:RC4-MD5:KRB5-DES-CBC3-MD5: KRB5-DES-CBC3-SHA

If the server is not capable of using one of the SSL Cipher Suites you configure, connection negotiation fails and the incident is recorded in the event log.


Note Use care in typing the cipher suite in the field. The ACE XML Manager web console does not verify the value you enter. If you mistype or otherwise enter a meaningless value, the Gateway will be unable to connect to the server.


Step 8 Click Save Changes to finish the server configuration.


The SSL configuration is now complete. After deploying the policy, virtual services that rely on the configured server will now use SSL to communicate with the backend server.