Contents

Overview of ACE SSL Troubleshooting

Secure Sockets Layer (SSL) runs over TCP. After the TCP three-way handshake completes and the ACE has proxied the connection, the SSL handshake takes place. For information about proxied connections, see the Troubleshooting Connectivity article. See Figure 1 for an illustration of the SSL handshake.

Figure 1. SSL Handshake

The ACE supports the following SSL configurations (see Figure 2):

SSL termination (ACE acts as an SSL server)

SSL initiation (ACE acts as a client)

End-to-end SSL (SSL termination plus SSL initiation)

Figure 2. SSL Configurations

Before you begin to troubleshoot potential SSL issues, be sure that the following conditions exist:

If you are running multiple ACEs in a redundant configuration, be sure that you have copied the SSL certificates (certs) and keys to the standby ACE. Certs and keys are not replicated in a redundant configuration from the active ACE to the standby ACE. Also, ensure that the configurations on the active and the standby are identical, including the same licenses and software versions.

4096 (high security, level 4) - For software release A2(2.4) and later in the ACE module and software release A3(2.6) and later in the ACE appliance, you can use 4096-bit SSL certificates in chaingroups and authgroups. You can also import public certificates and keys that are 4096 bits in length.

Server certs are valid, installed, and have not expired

Example of an SSL Termination Configuration

The following example shows a running-configuration file of the ACE acting as an SSL proxy server; terminating SSL or TLS connections from a client and then establishing a TCP connection to an HTTP server. When the ACE terminates the SSL or TLS connection, it decrypts the cipher text from the client and transmits the data as clear text to the HTTP server.

Example of an SSL Initiation Configuration

The following example shows a running-configuration file of the ACE acting as an SSL proxy client, initiating and maintaining an SSL connection between itself and an SSL server. The ACE receives clear text from an HTTP client, and then encrypts and transmits the data as cipher text to the SSL server. On the reverse side, the ACE decrypts the cipher text that it receives from the SSL server and sends the data to the client as clear text.

Troubleshooting ACE SSL

1. For the ACE module, check the health of the Nitrox-II (crypto module) and ensure that it has not become unresponsive. Stop all traffic, and then enter the following command:

ACE_module5/Admin# show crypto hardware

Figure 3. Example of the Show Crypto Hardware Command Output for an Unresponsive Crypto Module

STX1 is a count of the number of packets transmitted by the Nitrox-II and IMX1 is the number of packets received by the Nitrox-II. On a normal system, these values should be the same once traffic has stopped. If the values are not the same, the Nitrox-II has become unresponsive.

The Nitrox-II uses 0x500 TX buffers to transmit packets and 0x200 RX buffers to receive packets. If the [TR]X Buffers used count ever exceeds the amount available, the Nitrox-II has become unresponsive.

The available cores field shows which of the 22 cores of the Nitrox-II are active. When no traffic is flowing, there should be no numbers following the Using: statement. If there are, as in the sample output above, then that core (0 in this case) is hung, and the Nitrox-II has become unresponsive.

For the POM count, there are two numbers, A(B). The "A" value is the number of outstanding packets to the Packet Order Manager, while the "B" value, counts the number of packets that have been processed in the last second. When no traffic is flowing, both of these values should be 0. If no traffic is flowing, and the value of "A" is nonzero as shown above, then there are outstanding requests to the POM that are not being processed, because the Nitrox-II has become unresponsive.

2. Ensure that appropriate ports are designated for PAT in an SSL termination configuration. By default, connections to the real server from the ACE will inherit the destination port from the client to VIP connection so that a connection to port 443 on the VIP will go to port 443 on the real server, unless otherwise specified in the server farm configuration. This will cause problems if you are using ACE to offload SSL between the client and the VIP and send clear-text traffic to the real servers. The following example demonstrates a port definition in a server farm configuration: