Cisco ASA Unified Communications Guide
TLS Proxy for Encrypted Voice Inspection
Downloads: This chapterpdf (PDF - 570.0KB) | Feedback

Table of Contents

TLS Proxy for Encrypted Voice Inspection

Information About the TLS Proxy for Encrypted Voice Inspection

Decryption and Inspection of Unified Communications Encrypted Signaling

Supported Cisco UCM and IP Phones for the TLS Proxy

CTL Client Overview

Prerequisites for the TLS Proxy for Encrypted Voice Inspection

Configuring the TLS Proxy for Encrypted Voice Inspection (CLI)

Task flow for Configuring the TLS Proxy for Encrypted Voice Inspection

Creating Trustpoints and Generating Certificates

Creating an Internal CA

Creating a CTL Provider Instance

Creating the TLS Proxy Instance

Enabling the TLS Proxy Instance for Skinny or SIP Inspection

Configuring the TLS Proxy for Encrypted Voice Inspection (ASDM)

CTL Provider

Add/Edit CTL Provider

Configure TLS Proxy Pane

Adding a TLS Proxy Instance

Add TLS Proxy Instance Wizard – Server Configuration

Add TLS Proxy Instance Wizard – Client Configuration

Add TLS Proxy Instance Wizard – Other Steps

Edit TLS Proxy Instance – Server Configuration

Edit TLS Proxy Instance – Client Configuration

Edit the TLS Proxy

Add/Edit TLS Proxy

Monitoring the TLS Proxy

Feature History for the TLS Proxy for Encrypted Voice Inspection

Information About the TLS Proxy for Encrypted Voice Inspection

End-to-end encryption often leaves network security appliances “blind” to media and signaling traffic, which can compromise access control and threat prevention security functions. This lack of visibility can result in a lack of interoperability between the firewall functions and the encrypted voice, leaving businesses unable to satisfy both of their key security requirements.

The ASA is able to intercept and decrypt encrypted signaling from Cisco encrypted endpoints to the Cisco Unified Communications Manager (Cisco UCM), and apply the required threat protection and access control. It can also ensure confidentiality by re-encrypting the traffic onto the Cisco UCM servers.

Typically, the ASA TLS Proxy functionality is deployed in campus unified communications network. This solution is ideal for deployments that utilize end to end encryption and firewalls to protect Unified Communications Manager servers.

The security appliance in Figure 4-1 serves as a proxy for both client and server, with Cisco IP Phone and Cisco UCM interaction.

Figure 4-1 TLS Proxy Flow

 

Decryption and Inspection of Unified Communications Encrypted Signaling

With encrypted voice inspection, the security appliance decrypts, inspects and modifies (as needed, for example, performing NAT fixup), and re-encrypts voice signaling traffic while all of the existing VoIP inspection functions for Skinny and SIP protocols are preserved. Once voice signaling is decrypted, the plaintext signaling message is passed to the existing inspection engines.

The security appliance acts as a TLS proxy between the Cisco IP Phone and Cisco UCM. The proxy is transparent for the voice calls between the phone and theCisco UCM. Cisco IP Phones download a Certificate Trust List from the Cisco UCM before registration which contains identities (certificates) of the devices that the phone should trust, such as TFTP servers and Cisco UCM servers. To support server proxy, the CTL file must contain the certificate that the security appliance creates for the Cisco UCMs. To proxy calls on behalf of the Cisco IP Phone, the security appliance presents a certificate that the Cisco UCM can verify, which is a Local Dynamic Certificate for the phone, issued by the certificate authority on the security appliance.

TLS proxy is supported by the Cisco Unified CallManager Release 5.1 and later. You should be familiar with the security features of the Cisco UCM. For background and detailed description of Cisco UCM security, see the Cisco Unified CallManager document:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/sec_vir/ae/sec504/index.htm

TLS proxy applies to the encryption layer and must be configured with an application layer protocol inspection. You should be familiar with the inspection features on the ASA, especially Skinny and SIP inspection.

Supported Cisco UCM and IP Phones for the TLS Proxy

Cisco Unified Communications Manager

The following releases of the Cisco Unified Communications Manager are supported with the TLS proxy:

  • Cisco Unified CallManager Version 4. x
  • Cisco Unified CallManager Version 5.0
  • Cisco Unified CallManager Version 5.1
  • Cisco Unified Communications Manager 6.1
  • Cisco Unified Communications Manager 7.0
  • Cisco Unified Communications Manager 8.0
  • Cisco Unified Communications Manager 8.6

Cisco Unified IP Phones

The following IP phones in the Cisco Unified IP Phones 7900 Series are supported with the TLS proxy:

  • Cisco Unified IP Phone 7985
  • Cisco Unified IP Phone 7975
  • Cisco Unified IP Phone 7971
  • Cisco Unified IP Phone 7970
  • Cisco Unified IP Phone 7965
  • Cisco Unified IP Phone 7962
  • Cisco Unified IP Phone 7961
  • Cisco Unified IP Phone 7961G-GE
  • Cisco Unified IP Phone 7960
  • Cisco Unified IP Phone 7945
  • Cisco Unified IP Phone 7942
  • Cisco Unified IP Phone 7941
  • Cisco Unified IP Phone 7941G-GE
  • Cisco Unified IP Phone 7940
  • Cisco Unified Wireless IP Phone 7921
  • Cisco Unified Wireless IP Phone 7925
  • Cisco IP Communicator (CIPC) for softphones

CTL Client Overview

The CTL Client application supplied by Cisco Unified CallManager Release 5.1 and later supports a TLS proxy server (firewall) in the CTL file. Figure 4-2 through Figure 4-5 illustrate the TLS proxy features supported in the CTL Client.

Figure 4-2 CTL Client TLS Proxy Features — Add Firewall

 

Figure 4-2 shows support for adding a CTL entry consisting of the security appliance as the TLS proxy.

Figure 4-3 CTL Client TLS Proxy Features — ASA IP Address or Domain Name

 

Figure 4-3 shows support for entering the security appliance IP address or domain name in the CTL Client.

Figure 4-4 CTL Client TLS Proxy Features — CTL Entry for ASA

 

Figure 4-4 shows that the CTL entry for the security appliance as the TLS proxy has been added. The CTL entry is added after the CTL Client connects to the CTL Provider service on the security appliance and retrieves the proxy certificate.

 

Figure 4-5 CTL Client TLS Proxy Features — CTL File Installed on the ASA

 

The security appliance does not store the raw CTL file in the flash, rather, it parses the CTL file and installs appropriate trustpoints. Figure 4-5 indicates the installation was successful.

Prerequisites for the TLS Proxy for Encrypted Voice Inspection

Before configuring TLS proxy, the following prerequisites are required:

  • You must set clock on the security appliance before configuring TLS proxy. To set the clock manually and display clock, use the clock set and show clock commands. We recommend that the security appliance use the same NTP server as the Cisco Unified CallManager cluster. TLS handshake may fail due to certificate validation failure if clock is out of sync between the security appliance and the Cisco Unified CallManager server.
  • 3DES-AES license is needed to interoperate with the Cisco Unified CallManager. AES is the default cipher used by the Cisco Unified CallManager and Cisco IP Phone.
  • Import the following certificates which are stored on the Cisco UCM. These certificates are required by the ASA for the phone proxy.

Cisco_Manufacturing_CA

CAP-RTP-001

CAP-RTP-002

CAPF certificate (Optional)

If LSC provisioning is required or you have LSC enabled IP phones, you must import the CAPF certificate from the Cisco UCM. If the Cisco UCM has more than one CAPF certificate, you must import all of them to the ASA.

See Chapter3, “Cisco Phone Proxy”For example, the CA Manufacturer certificate is required by the phone proxy to validate the IP phone certificate.

Configuring the TLS Proxy for Encrypted Voice Inspection (CLI)

Task flow for Configuring the TLS Proxy for Encrypted Voice Inspection

To configure the security appliance for TLS proxy, perform the following steps:


Step 1 (Optional) Set the maximum number of TLS proxy sessions to be supported by the security appliance using the following command, for example:

ciscoasa(config)# tls-proxy maximum-sessions 1200
 

Note The tls-proxy maximum-sessions command controls the memory size reserved for cryptographic applications such as TLS proxy. Crypto memory is reserved at the time of system boot. You may need to reboot the security appliance for the configuration to take effect if the configured maximum sessions number is greater than the currently reserved.


Step 2 Create trustpoints and generate certificates for the TLS Proxy for Encrypted Voice Inspection. See Creating Trustpoints and Generating Certificates.

Step 3 Create the internal CA to sign the LDC for Cisco IP Phones. See Creating an Internal CA.

Step 4 Create the CTL provider instance. See Creating a CTL Provider Instance.

Step 5 Create the TLS proxy instance. See Creating the TLS Proxy Instance.

Step 6 Enable the TLS proxy y with SIP and Skinny inspection. See Enabling the TLS Proxy Instance for Skinny or SIP Inspection.

Step 7 Export the local CA certificate (ldc_server) and install it as a trusted certificate on the Cisco UCM server.

a. Use the following command to export the certificate if a trust-point with proxy-ldc-issuer is used as the signer of the dynamic certificates, for example:

ciscoasa(config)# crypto ca export ldc_server identity-certificate
 

b. For the embedded local CA server LOCAL-CA-SERVER, use the following command to export its certificate, for example:

ciscoasa(config)# show crypto ca server certificate
 

Save the output to a file and import the certificate on the Cisco UCM. For more information, see the Cisco Unified CallManager document: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/iptp_adm/504/iptpch6.htm#wp1040848

After this step, you may use the Display Certificates function on the Cisco Unified CallManager GUI to verify the installed certificate:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/iptp_adm/504/iptpch6.htm#wp1040354

Step 8 Run the CTL Client application to add the server proxy certificate (ccm_proxy) to the CTL file and install the CTL file on the security appliance. See the Cisco Unified CallManager document for information on how to configure and use CTL Client:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_1/nci/p08/secuauth.htm


Note You will need the CTL Client that is released with Cisco Unified CallManager Release 5.1 to interoperate with the security appliance. See CTL Client Overview for more information regarding TLS proxy support.



 

Creating Trustpoints and Generating Certificates

The Cisco UCM proxy certificate could be self-signed or issued by a third-party CA. The certificate is exported to the CTL client.

Prerequisites

Import the required certificates, which are stored on the Cisco UCM. See Certificates from the Cisco UCM and the Importing Certificates from the Cisco UCM.

 

Command
Purpose

Step 1

hostname(config)# crypto key generate rsa label key-pair-label modulus size
Examples:
ciscoasa(config)# crypto key generate rsa label ccm_proxy_key modulus 1024
ciscoasa(config)# crypto key generate rsa label ldc_signer_key modulus 1024
ciscoasa(config)# crypto key generate rsa label phone_common modulus 1024

Creates the RSA keypair that can be used for the trustpoints.

The keypair is used by the self-signed certificate presented to the local domain containing the Cisco UP (proxy for the remote entity).

Note We recommend that you create a different key pair for each role.

Step 2

ciscoasa(config)# crypto ca trustpoint trustpoint_name
Example:
ciscoasa(config)# ! for self-signed CCM proxy certificate
ciscoasa(config)# crypto ca trustpoint ccm_proxy

Enters the trustpoint configuration mode for the specified trustpoint so that you can create the trustpoint for the Cisco UMA server.

A trustpoint represents a CA identity and possibly a device identity, based on a certificate issued by the CA.

Step 3

ciscoasa(config-ca-trustpoint)# enrollment self

Generates a self-signed certificate.

Step 4

ciscoasa(config-ca-trustpoint)# fqdn none

Specifies not to include a fully qualified domain name (FQDN) in the Subject Alternative Name extension of the certificate during enrollment.

Step 5

ciscoasa(config-ca-trustpoint)# subject-name X.500_name
Example:
ciscoasa(config-ca-trustpoint)# subject-name cn=EJW-SV-1-Proxy

Includes the indicated subject DN in the certificate during enrollment

Cisco IP Phones require certain fields from the X.509v3 certificate to be present to validate the certificate via consulting the CTL file. Consequently, the subject-name entry must be configured for a proxy certificate trustpoint. The subject name must be composed of the ordered concatenation of the CN, OU and O fields. The CN field is mandatory; the others are optional.


Note Each of the concatenated fields (when present) are separated by a semicolon, yielding one of the following forms:
CN=xxx;OU=yyy;O=zzz
CN=xxx;OU=yyy
CN=xxx;O=zzz
CN=xxx


Step 6

hostname(config-ca-trustpoint)# keypair keyname
Example:
ciscoasa(config-ca-trustpoint)# keypair ccm_proxy_key

Specifies the key pair whose public key is to be certified.

Step 7

hostname(config-ca-trustpoint)# exit

Exits from the CA Trustpoint configuration mode.

Step 8

hostname(config)# crypto ca enroll trustpoint
Example:
ciscoasa(config)# crypto ca enroll ccm_proxy

Starts the enrollment process with the CA and specifies the name of the trustpoint to enroll with.

What to Do Next

Once you have created the trustpoints and generated the certificates, create the internal CA to sign the LDC for Cisco IP Phones. See Creating an Internal CA.

Creating an Internal CA

Create an internal local CA to sign the LDC for Cisco IP Phones.

This local CA is created as a regular self-signed trustpoint with proxy-ldc-issuer enabled. You can use the embedded local CA LOCAL-CA-SERVER on the ASA to issue the LDC.

 

Command
Purpose

Step 1

ciscoasa(config)# crypto ca trustpoint trustpoint_name
Example:
ciscoasa(config)# ! for the internal local LDC issuer
ciscoasa(config)# crypto ca trustpoint ldc_server

Enters the trustpoint configuration mode for the specified trustpoint so that you can create the trustpoint for the LDC issurer.

Step 2

ciscoasa(config-ca-trustpoint)# enrollment self

Generates a self-signed certificate.

Step 3

ciscoasa(config-ca-trustpoint)# proxy-ldc-issuer

Issues TLS proxy local dynamic certificates. The proxy-ldc-issuer command grants a crypto trustpoint the role as local CA to issue the LDC and can be accessed from crypto ca trustpoint configuration mode.

The proxy-ldc-issuer command defines the local CA role for the trustpoint to issue dynamic certificates for TLS proxy. This command can only be configured under a trustpoint with "enrollment self."

Step 4

ciscoasa(config-ca-trustpoint)# fqdn fqdn
Example:
ciscoasa(config-ca-trustpoint)# fqdn my-ldc-ca.exmaple.com

Includes the indicated FQDN in the Subject Alternative Name extension of the certificate during enrollment.

Step 5

ciscoasa(config-ca-trustpoint)# subject-name X.500_name
Example:
ciscoasa(config-ca-trustpoint)# subject-name cn=FW_LDC_SIGNER_172_23_45_200

Includes the indicated subject DN in the certificate during enrollment

Step 6

hostname(config-ca-trustpoint)# keypair keyname
Example:
ciscoasa(config-ca-trustpoint)# keypair ldc_signer_key

Specifies the key pair whose public key is to be certified.

Step 7

ciscoasa(config-ca-trustpoint)# exit

Exits from the CA Trustpoint configuration mode.

Step 8

hostname(config)# crypto ca enroll trustpoint
Example:
ciscoasa(config)# crypto ca enroll ldc_server

Starts the enrollment process with the CA and specifies the name of the trustpoint to enroll with.

What to Do Next

Once you have created the internal CA, create the CTL provider instance. See Creating a CTL Provider Instance.

Creating a CTL Provider Instance

Create a CTL Provider instance in preparation for a connection from the CTL Client.

The default port number listened by the CTL Provider is TCP 2444, which is the default CTL port on the Cisco UCM. Use the service port command to change the port number if a different port is used by the Cisco UCM cluster.

 

Command
Purpose

Step 1

ciscoasa(config)# ctl-provider ctl_name
Example:
ciscoasa(config)# ctl-provider my_ctl

Enters the CTL provider configuration mode so that you can create the Certificate Trust List provider instance.

Step 2

ciscoasa(config-ctl-provider)# client interface if_name ipv4_addr
Example:
ciscoasa(config-ctl-provider)# client interface inside address 172.23.45.1

Specifies clients allowed to connect to the Certificate Trust List provider.

Where interface if_name specifies the interface allowed to connect and ipv4_addr specifies the IP address of the client.

More than one command may be issued to define multiple clients.

Step 3

ciscoasa(config-ctl-provider)# client username user_name password password encrypted
Example:
ciscoasa(config-ctl-provider)# client username CCMAdministrator password XXXXXX encrypted

Specifies the username and password for client authentication.

The username and password must match the username and password for Cisco UCM administration.

Step 4

ciscoasa(config-ctl-provider)# export certificate trustpoint_name
Example:

ciscoasa(config-ctl-provider)# export certificate

Specifies the certificate to be exported to the client. The certificate will be added to the Certificate Trust List file composed by the CTL client.

The trustpoint name in the export command is the proxy certificate for the Cisco UCM server.

Step 5

ciscoasa(config-ctl-provider)# ctl install

Enables the CTL provider to parse the CTL file from the CTL client and install trustpoints for entries from the CTL file. Ttrustpoints installed by this command have names prefixed with "_internal_CTL_<ctl_name>."

What to Do Next

Once you have created the CTL provider instance, create the TLS proxy instance. See Creating the TLS Proxy Instance.

Creating the TLS Proxy Instance

Create the TLS proxy instance to handle the encrypted signaling.

 

Command
Purpose

Step 1

ciscoasa(config)# tls-proxy proxy_name
Example:
ciscoasa(config)# tls-proxy my_proxy

Creates the TLS proxy instance.

Step 2

ciscoasa(config-tlsp)# server trust-point proxy_trustpoint
Example:
ciscoasa(config-tlsp)# server trust-point ccm_proxy

Specifies the proxy trustpoint certificate to present during TLS handshake.

The server command configures the proxy parameters for the original TLS server. In other words, the parameters for the ASA to act as the server during a TLS handshake, or facing the original TLS client.

Step 3

ciscoasa(config-tlsp)# client ldc issuer ca_tp_name
Example:
ciscoasa(config-tlsp)# client ldc issuer ldc_server

Sets the local dynamic certificate issuer. The local CA to issue client dynamic certificates is defined by the crypto ca trustpoint command and the trustpoint must have proxy-ldc-issuer configured, or the default local CA server (LOCAL-CA-SERVER).

Where ldc issuer ca_tp_name specifies the local CA trustpoint to issue client dynamic certificates.

Step 4

ciscoasa(config-tlsp)# client ldc key-pair key_label
Example:
ciscoasa(config-tlsp)# client ldc key-pair phone_common

Sets the keypair.

The keypair value must have been generated with the crypto key generate command.

Step 5

hostname(config-tlsp)# client cipher-suite cipher_suite
Example:
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1

Sets the user-defined cipher suite.

For client proxy (the proxy acts as a TLS client to the server), the user-defined cipher suite replaces the default cipher suite, or the one defined by the ssl encryption command. You can use this command to achieve difference ciphers between the two TLS sessions. You should use AES ciphers with the CallManager server.

What to Do Next

Once you have created TLS proxy instance, enable the TLS proxy instance for Skinny and SIP inspection. See Enabling the TLS Proxy Instance for Skinny or SIP Inspection.

Enabling the TLS Proxy Instance for Skinny or SIP Inspection

Enable TLS proxy for the Cisco IP Phones and Cisco UCMs in Skinny or SIP inspection. The following procedure shows how to enable the TLS proxy instance for Skinny inspection.

 

Command
Purpose

Step 1

hostname(config)# class-map class_map_name
Example:
ciscoasa(config)# class-map sec_skinny

Configures the secure Skinny class of traffic to inspect.

Where class_map_name is the name of the Skinny class map.

Step 2

ciscoasa(config-cmap)# match port tcp eq 2443

Matches the TCP port 2443 to which you want to apply actions for secure Skinny inspection

Step 3

ciscoasa(config-cmap)# exit

 

Step 4

hostname(config)# policy-map type inspect skinny policy_map_name
Example:
ciscoasa(config)# policy-map type inspect skinny skinny_inspect

Defines special actions for Skinny inspection application traffic.

Step 5

ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)# ! Skinny inspection parameters

Specifies the parameters for Skinny inspection. Parameters affect the behavior of the inspection engine.

The commands available in parameters configuration mode depend on the application.

Step 6

ciscoasa(config-pmap-p)# exit

Exits from Policy Map configuration mode.

Step 7

hostname(config)# policy-map name
Example:
ciscoasa(config)# policy-map global_policy

Configure the policy map and attach the action to the class of traffic.

Step 8

ciscoasa(config-pmap)# class inspection_default

Specifies the default class map.

The configuration includes a default Layer 3/4 class map that the ASA uses in the default global policy. It is called inspection_default and matches the default inspection traffic,

Step 9

ciscoasa(config-pmap-c)# inspect skinny skinny_map
Example:
ciscoasa(config-pmap-c)# inspect skinny skinny_inspect

Enables SCCP (Skinny) application inspection.

Step 10

ciscoasa(config-pmap)# class classmap_name
Example:
ciscoasa(config-pmap)# class sec_skinny

Assigns a class map to the policy map where you can assign actions to the class map traffic.

Step 11

ciscoasa(config-pmap-c)# inspect skinny skinny_map tls-proxy proxy_name
Example:
ciscoasa(config-pmap-c)# inspect skinny skinny_inspect tls-proxy my_proxy

Enables TLS proxy for the specified inspection session.

Step 12

ciscoasa(config-pmap-c)# exit

Exits from the Policy Map configuration mode.

Step 13

ciscoasa(config)# service-policy policymap_name global
Example:
ciscoasa(config)# service-policy global_policy global

Enables the service policy on all interfaces.

 

Configuring the TLS Proxy for Encrypted Voice Inspection (ASDM)

CTL Provider

Use the CTL Provider option to configure Certificate Trust List provider service.

The CTL Provider pane lets you define and configure Certificate Trust List provider service to enable inspection of encrypted traffic.

Fields

  • CTL Provider Name—Lists the CTL Provider name.
  • Client Details—Lists the name and IP address of the client.

Interface Name—Lists the defined interface name.

IP Address—Lists the defined interface IP address.

  • Certificate Name—Lists the certificate to be exported.
  • Add—Adds a CTL Provider.
  • Edit—Edits a CTL Provider.
  • Delete—Deletes a CTL Provider.

Add/Edit CTL Provider

The Add/Edit CTL Provider dialog box lets you define the parameters for the CTL Provider.

Fields

  • CTL Provider Name—Specifies the CTL Provider name.
  • Certificate to be Exported—Specifies the certificate to be exported to the client.

Certificate Name—Specifies the name of the certificate to be exported to the client.

Manage—Manages identity certificates.

  • Client Details—Specifies the clients allowed to connect.

Client to be Added—Specifies the client interface and IP address to add to the client list.

Interface—Specifies client interface.

IP Address—Specifies the client IP address.

Add—Adds the new client to the client list.

Delete—Deletes the selected client from the client list.

  • More Options—Specifies the available and active algorithms to be announced or matched during the TLS handshake.

Parse the CTL file provided by the CTL Client and install trustpoints—Trustpoints installed by this option have names prefixed with “_internal_CTL_.” If disabled, each Call Manager server and CAPF certificate must be manually imported and installed.

Port Number—Specifies the port to which the CTL provider listens. The port must be the same as the one listened to by the CallManager servers in the cluster (as configured under Enterprise Parameters on the CallManager administration page). The default is 2444.

Authentication—Specifies the username and password that the client authenticates with the provider.

Username—Client username.

Password—Client password.

Confirm Password—Client password.

 

Configure TLS Proxy Pane


NoteThis feature is not supported for the Adaptive Security Appliance version 8.1.2. This feature is not supported for the Adaptive Security Appliance version 8.1.2.


You can configure the TLS Proxy from the Configuration > Firewall > Unified Communications > TLS Proxy pane.

Configuring a TLS Proxy lets you use the TLS Proxy to enable inspection of SSL encrypted VoIP signaling, namely Skinny and SIP, interacting with Cisco Call Manager and enable the ASA for the Cisco Unified Communications features:

  • TLS Proxy for the Cisco Unified Presence Server (CUPS), part of Presence Federation
  • TLS Proxy for the Cisco Unified Mobility Advantage (CUMA) server, part of Mobile Advantage
  • Phone Proxy

Fields

  • TLS Proxy Name—Lists the TLS Proxy name.
  • Server Proxy Certificate—Lists the trustpoint, which is either self-signed or enrolled with a certificate server.
  • Local Dynamic Certificate Issuer—Lists the local certificate authority to issue client or server dynamic certificates.
  • Client Proxy Certificate—Lists the proxy certificate for the TLS client. The ASA uses the client proxy certificate to authenticate the TLS client during the handshake between the proxy and the TLS client. The certificate can be either self-signed, enrolled with a certificate authority, or issued by the third party.
  • Add—Adds a TLS Proxy by launching the Add TLS Proxy Instance Wizard. See Adding a TLS Proxy Instance for the steps to create a TLS Proxy instance.
  • Edit—Edits a TLS Proxy. The fields in the Edit panel area identical to the fields displayed when you add a TLS Proxy instance. See Edit TLS Proxy Instance – Server Configuration and Edit TLS Proxy Instance – Client Configuration.
  • Delete—Deletes a TLS Proxy.
  • Maximum Sessions—Lets you specify the maximum number of TLS Proxy sessions to support.

Specify the maximum number of TLS Proxy sessions that the ASA needs to support.

Maximum number of sessions—The minimum is 1. The maximum is dependent on the platform.


Note The maximum number of sessions is global to all TLS proxy sessions.


Adding a TLS Proxy Instance


NoteThis feature is not supported for the Adaptive Security Appliance version 8.1.2. This feature is not supported for the Adaptive Security Appliance version 8.1.2.


Use the Add TLS Proxy Instance Wizard to add a TLS Proxy to enable inspection of SSL encrypted VoIP signaling, namely Skinny and SIP, interacting with Cisco Call Manager and to support the Cisco Unified Communications features on the ASA.

This wizard is available from the Configuration > Firewall > Unified Communications > TLS Proxy pane.


Step 1 Open the Configuration > Firewall > Unified Communications > TLS Proxy pane.

Step 2 To add a new TLS Proxy Instance, click Add .

The Add TLS Proxy Instance Wizard opens.

Step 3 In the TLS Proxy Name field, type the TLS Proxy name.

Step 4 Click Next .

The Add TLS Proxy Instance Wizard – Server Configuration dialog box opens. In this step of the wizard, configure the server proxy parameters for original TLS Server—the Cisco Unified Call Manager (CUCM) server, the Cisco Unified Presence Server (CUPS), or the Cisco Unified Mobility Advantage (CUMA) server. See Add TLS Proxy Instance Wizard – Server Configuration.

After configuring the server proxy parameters, the wizard guides you through configuring client proxy parameters (see Add TLS Proxy Instance Wizard – Client Configuration) and provides instructions on the steps to complete outside the ASDM to make the TLS Proxy fully functional (see Add TLS Proxy Instance Wizard – Other Steps).


 

Add TLS Proxy Instance Wizard – Server Configuration


NoteThis feature is not supported for the Adaptive Security Appliance version 8.1.2. This feature is not supported for the Adaptive Security Appliance version 8.1.2.


Use the Add TLS Proxy Instance Wizard to add a TLS Proxy to enable inspection of SSL encrypted VoIP signaling, namely Skinny and SIP, interacting with Cisco Call Manager and to support the Cisco Unified Communications features on the ASA.

The Add TLS Proxy Instance Wizard is available from the Configuration > Firewall > Unified Communications > TLS Proxy pane.


Step 1 Complete the first step of the Add TLS Proxy Instance Wizard. See Adding a TLS Proxy Instance.

The Add TLS Proxy Instance Wizard – Server Configuration dialog box opens.

Step 2 Specify the server proxy certificate by doing one of the following:

    • To add a new certificate, click Manage . The Manage Identify Certificates dialog box opens.

When the Phone Proxy is operating in a mixed-mode CUCM cluster, you must import the CUCM certificate by clicking Add in the Manage Identify Certificates dialog box.

    • To select an existing certificate, select one from the drop-down list.

When you are configuring the TLS Proxy for the Phone Proxy, select the certificate that has a filename beginning with _internal_PP_ . When you create the CTL file for the Phone Proxy, the ASA, creates an internal trustpoint used by the Phone Proxy to sign the TFTP files. The trustpoint is named _internal_PP_ ctl-instance_filename .

The server proxy certificate is used to specify the trustpoint to present during the TLS handshake. The trustpoint can be self-signed or enrolled locally with the certificate service on the proxy. For example, for the Phone Proxy, the server proxy certificate is used by the Phone Proxy during the handshake with the IP phones.

Step 3 To install the TLS server certificate in the ASA trust store, so that the ASA can authenticate the TLS server during TLS handshake between the proxy and the TLS server, click Install TLS Server’s Certificate .

The Manage CA Certificates dialog box opens. Click Add to open the Install Certificate dialog box.

When you are configuring the TLS Proxy for the Phone Proxy, click Install TLS Server’s Certificate and install the Cisco Unified Call Manager (CUCM) certificate so that the proxy can authenticate the IP phones on behalf of the CUCM server.

Step 4 To require the ASA to present a certificate and authenticate the TLS client during TLS handshake, check the Enable client authentication during TLS Proxy handshake check box.

When adding a TLS Proxy Instance for Mobile Advantage (the CUMC client and CUMA server), disable the check box when the client is incapable of sending a client certificate.

Step 5 Click Next .

The Add TLS Proxy Instance Wizard – Client Configuration dialog box opens. In this step of the wizard, configure the client proxy parameters for original TLS Client—the CUMC client for Mobile Advantage, CUP or MS LCS/OCS client for Presence Federation, or the IP phone for the Phone Proxy. See Add TLS Proxy Instance Wizard – Client Configuration.

After configuring the client proxy parameters, the wizard provides instructions on the steps to complete outside the ASDM to make the TLS Proxy fully functional (see Add TLS Proxy Instance Wizard – Other Steps).


 

Add TLS Proxy Instance Wizard – Client Configuration


NoteThis feature is not supported for the Adaptive Security Appliance version 8.1.2. This feature is not supported for the Adaptive Security Appliance version 8.1.2.


Use the Add TLS Proxy Instance Wizard to add a TLS Proxy to enable inspection of SSL encrypted VoIP signaling, namely Skinny and SIP, interacting with Cisco Call Manager and to support the Cisco Unified Communications features on the ASA.

This wizard is available from the Configuration > Firewall > Unified Communications > TLS Proxy pane.


Step 1 Complete the first two steps of the Add TLS Proxy Instance Wizard. See Adding a TLS Proxy Instance and Add TLS Proxy Instance Wizard – Client Configuration.

The Add TLS Proxy Instance Wizard – Client Configuration dialog box opens.

Step 2 To specify a client proxy certificate to use for the TLS Proxy, perform the following. Select this option when the client proxy certificate is being used between two servers; for example, when configuring the TLS Proxy for Presence Federation, which uses the Cisco Unified Presence Server (CUPS), both the TLS client and TLS server are both servers.

a. Check the Specify the proxy certificate for the TLS Client... check box.

b. Select a certificate from the drop-down list.

Or

To create a new client proxy certificate, click Manage . The Manage Identify Certificates dialog box opens.


NoteWhen you are configuring the TLS Proxy for the Phone Proxy and it is using the mixed security mode for the CUCM cluster, you must configure the LDC Issuer. The LDC Issuer lists the local certificate authority to issue client or server dynamic certificates. When you are configuring the TLS Proxy for the Phone Proxy and it is using the mixed security mode for the CUCM cluster, you must configure the LDC Issuer. The LDC Issuer lists the local certificate authority to issue client or server dynamic certificates.


Step 3 To specify an LDC Issuer to use for the TLS Proxy, perform the following. When you select and configure the LDC Issuer option, the ASA acts as the certificate authority and issues certificates to TLS clients.

a. Click the Specify the internal Certificate Authority to sign the local dynamic certificate for phones... check box.

b. Click the Certificates radio button and select a self-signed certificate from the drop-down list or click Manage to create a new LDC Issuer. The Manage Identify Certificates dialog box opens.

Or

Click the Certificate Authority radio button to specify a Certificate Authority (CA) server. When you specify a CA server, it needs to be created and enabled in the ASA. To create and enable the CA server, click Manage . The Edit CA Server Settings dialog box opens.


Note To make configuration changes after the local certificate authority has been configured for the first time, disable the local certificate authority.


c. In the Key-Pair Name field, select a key pair from the drop-list. The list contains the already defined RSA key pair used by client dynamic certificates. To see the key pair details, including generation time, usage, modulus size, and key data, click Show .

Or

To create a new key pair, click New . The Add Key Pair dialog box opens.

Step 4 In the Security Algorithms area, specify the available and active algorithms to be announced or matched during the TLS handshake.

  • Available Algorithms—Lists the available algorithms to be announced or matched during the TLS handshake: des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, and null-sha1.

Add—Adds the selected algorithm to the active list.

Remove—Removes the selected algorithm from the active list.

  • Active Algorithms—Lists the active algorithms to be announced or matched during the TLS handshake: des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, and null-sha1. For client proxy (acting as a TLS client to the server), the user-defined algorithms replace the original ones from the hello message for asymmetric encryption method between the two TLS legs. For example, the leg between the proxy and Call Manager may be NULL cipher to offload the Call Manager.

Move Up—Moves an algorithm up in the list.

Move Down—Moves an algorithm down in the list.

Step 5 Click Next .

The Add TLS Proxy Instance Wizard – Other Steps dialog box opens. The Other Steps dialog box provides instructions on the steps to complete outside the ASDM to make the TLS Proxy fully functional (see Add TLS Proxy Instance Wizard – Other Steps).


 

Add TLS Proxy Instance Wizard – Other Steps


NoteThis feature is not supported for the Adaptive Security Appliance version 8.1.2. This feature is not supported for the Adaptive Security Appliance version 8.1.2.


The last dialog box of the Add TLS Proxy Instance Wizard specifies the additional steps required to make TLS Proxy fully functional. In particular, you need to perform the following tasks to complete the TLS Proxy configuration:

  • Export the local CA certificate or LDC Issuer and install them on the original TLS server.

To export the LDC Issuer, go to Configuration > Firewall > Advanced > Certificate Management > Identity Certificates > Export. See the general operations configuration guide.

  • For the TLS Proxy, enable Skinny and SIP inspection between the TLS server and TLS clients. When you are configuring the TLS Proxy for Presence Federation (which uses CUP), you only enable SIP inspection because the feature supports only the SIP protocol.
  • For the TLS Proxy for CUMA, enable MMP inspection.
  • When using the internal Certificate Authority of the ASA to sign the LDC Issuer for TLS clients, perform the following:

Use the Cisco CTL Client to add the server proxy certificate to the CTL file and install the CTL file on the ASA.

For information on the Cisco CTL Client, see “Configuring the Cisco CTL Client” in Cisco Unified CallManager Security Guide .

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/5_0_4/secuauth.html

To install the CTL file on the ASA, go to Configuration > Firewall > Unified Communications > CTL Provider > Add. The Add CTL Provider dialog box opens. For information on using this dialog box to install the CTL file, see Add/Edit CTL Provider.

Create a CTL provider instance for connections from the CTL clients. See Add/Edit CTL Provider.

Edit TLS Proxy Instance – Server Configuration


NoteThis feature is not supported for the Adaptive Security Appliance version 8.1.2. This feature is not supported for the Adaptive Security Appliance version 8.1.2.


The TLS Proxy enables inspection of SSL encrypted VoIP signaling, namely Skinny and SIP, interacting with Cisco Call Manager and to support the Cisco Unified Communications features on the ASA.

Use the Edit TLS Proxy – Server Configuration tab to edit the server proxy parameters for the original TLS Server—the Cisco Unified Call Manager (CUCM) server, the Cisco Unified Presence Server (CUPS), or the Cisco Unified Mobility Advantage (CUMA) server.


Step 1 Open the Configuration > Firewall > Unified Communications > TLS Proxy pane.

Step 2 To edit a TLS Proxy Instance, click Edit .

The Edit TLS Proxy Instance dialog box opens.

Step 3 If necessary, click the Server Configuration tab.

Step 4 Specify the server proxy certificate by doing one of the following:

    • To add a new certificate, click Manage . The Manage Identify Certificates dialog box opens.

When the Phone Proxy is operating in a mixed-mode CUCM cluster, you must import the CUCM certificate by clicking Add in the Manage Identify Certificates dialog box.

    • To select an existing certificate, select one from the drop-down list.

When you are configuring the TLS Proxy for the Phone Proxy, select the certificate that has a filename beginning with _internal_PP_ . When you create the CTL file for the Phone Proxy, the ASA, creates an internal trustpoint used by the Phone Proxy to sign the TFTP files. The trustpoint is named _internal_PP_ ctl-instance_filename .

The server proxy certificate is used to specify the trustpoint to present during the TLS handshake. The trustpoint can be self-signed or enrolled locally with the certificate service on the proxy. For example, for the Phone Proxy, the server proxy certificate is used by the Phone Proxy during the handshake with the IP phones.

Step 5 To install the TLS server certificate in the ASA trust store, so that the ASA can authenticate the TLS server during TLS handshake between the proxy and the TLS server, click Install TLS Server’s Certificate .

The Manage CA Certificates dialog box opens. Click Add to open the Install Certificate dialog box.

When you are configuring the TLS Proxy for the Phone Proxy, click Install TLS Server’s Certificate and install the Cisco Unified Call Manager (CUCM) certificate so that the proxy can authenticate the IP phones on behalf of the CUCM server.

Step 6 To require the ASA to present a certificate and authenticate the TLS client during TLS handshake, check the Enable client authentication during TLS Proxy handshake check box.

When adding a TLS Proxy Instance for Mobile Advantage (the CUMC client and CUMA server), disable the check box when the client is incapable of sending a client certificate.

Step 7 Click Apply to save the changes.


 

Edit TLS Proxy Instance – Client Configuration


NoteThis feature is not supported for the Adaptive Security Appliance version 8.1.2. This feature is not supported for the Adaptive Security Appliance version 8.1.2.


The TLS Proxy enables inspection of SSL encrypted VoIP signaling, namely Skinny and SIP, interacting with Cisco Call Manager and to support the Cisco Unified Communications features on the ASA.

The fields in the Edit TLS Proxy dialog box are identical to the fields displayed when you add a TLS Proxy instance. Use the Edit TLS Proxy – Client Configuration tab to edit the client proxy parameters for the original TLS Client, such as IP phones, CUMA clients, the Cisco Unified Presence Server (CUPS), or the Microsoft OCS server.


Step 1 Open the Configuration > Firewall > Unified Communications > TLS Proxy pane.

Step 2 To edit a TLS Proxy Instance, click Edit .

The Edit TLS Proxy Instance dialog box opens.

Step 3 If necessary, click the Client Configuration tab.

Step 4 To specify a client proxy certificate to use for the TLS Proxy, perform the following. Select this option when the client proxy certificate is being used between two servers; for example, when configuring the TLS Proxy for Presence Federation, which uses the Cisco Unified Presence Server (CUPS), both the TLS client and TLS server are both servers.

a. Check the Specify the proxy certificate for the TLS Client... check box.

b. Select a certificate from the drop-down list.

Or

To create a new client proxy certificate, click Manage . The Manage Identify Certificates dialog box opens.


NoteWhen you are configuring the TLS Proxy for the Phone Proxy and it is using the mixed security mode for the CUCM cluster, you must configure the LDC Issuer. The LDC Issuer lists the local certificate authority to issue client or server dynamic certificates. When you are configuring the TLS Proxy for the Phone Proxy and it is using the mixed security mode for the CUCM cluster, you must configure the LDC Issuer. The LDC Issuer lists the local certificate authority to issue client or server dynamic certificates.


Step 5 To specify an LDC Issuer to use for the TLS Proxy, perform the following. When you select and configure the LDC Issuer option, the ASA acts as the certificate authority and issues certificates to TLS clients.

a. Click the Specify the internal Certificate Authority to sign the local dynamic certificate for phones... check box.

b. Click the Certificates radio button and select a self-signed certificate from the drop-down list or click Manage to create a new LDC Issuer. The Manage Identify Certificates dialog box opens.

Or

Click the Certificate Authority radio button to specify a Certificate Authority (CA) server. When you specify a CA server, it needs to be created and enabled in the ASA. To create and enable the CA server, click Manage . The Edit CA Server Settings dialog box opens.


Note To make configuration changes after the local certificate authority has been configured for the first time, disable the local certificate authority.


c. In the Key-Pair Name field, select a key pair from the drop-list. The list contains the already defined RSA key pair used by client dynamic certificates. To see key pair details, including generation time, usage, modulus size, and key data, click Show .

Or

To create a new key pair, click New . The Add Key Pair dialog box opens.

Step 6 In the Security Algorithms area, specify the available and active algorithms to be announced or matched during the TLS handshake.

  • Available Algorithms—Lists the available algorithms to be announced or matched during the TLS handshake: des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, and null-sha1.

Add—Adds the selected algorithm to the active list.

Remove—Removes the selected algorithm from the active list.

  • Active Algorithms—Lists the active algorithms to be announced or matched during the TLS handshake: des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, and null-sha1. For client proxy (acting as a TLS client to the server), the user-defined algorithms replace the original ones from the hello message for asymmetric encryption method between the two TLS legs. For example, the leg between the proxy and Call Manager may be NULL cipher to offload the Call Manager.

Move Up—Moves an algorithm up in the list.

Move Down—Moves an algorithm down in the list.

Step 7 Click Apply to save the changes.


 

Edit the TLS Proxy

Use the TLS Proxy option to enable inspection of SSL encrypted VoIP signaling, namely Skinny and SIP, interacting with Cisco CallManager.

The TLS Proxy pane lets you define and configure Transaction Layer Security Proxy to enable inspection of encrypted traffic.

Fields

  • TLS Proxy Name—Lists the TLS Proxy name.
  • Server—Lists the trustpoint, which is either self-signed or enrolled with a certificate server.
  • Local Dynamic Certificate Issuer—Lists the local certificate authority to issue client or server dynamic certificates.
  • Local Dynamic Certificate Key Pair—Lists the RSA key pair used by client or server dynamic certificates.
  • Add—Adds a TLS Proxy.
  • Edit—Edits a TLS Proxy.
  • Delete—Deletes a TLS Proxy.
  • Maximum Sessions—Lets you specify the maximum number of TLS Proxy sessions to support.

Specify the maximum number of TLS Proxy sessions that the ASA needs to support. By default, ASA supports 300 sessions.—Enables maximum number of sessions option.

Maximum number of sessions:—The minimum is 1. The maximum is dependent on the platform. The default is 300.

Add/Edit TLS Proxy


NoteThis feature is not supported for the Adaptive Security Appliance versions prior to 8.0.4 and for version 8.1.2. This feature is not supported for the Adaptive Security Appliance versions prior to 8.0.4 and for version 8.1.2.


The Add/Edit TLS Proxy dialog box lets you define the parameters for the TLS Proxy.

Fields

  • TLS Proxy Name—Specifies the TLS Proxy name.
  • Server Configuration—Specifies the proxy certificate name.

Server—Specifies the trustpoint to be presented during the TLS handshake. The trustpoint could be self-signed or enrolled locally with the certificate service on the proxy.

  • Client Configuration—Specifies the local dynamic certificate issuer and key pair.

Local Dynamic Certificate Issuer—Lists the local certificate authority to issue client or server dynamic certificates.

Certificate Authority Server—Specifies the certificate authority server.

Certificate—Specifies a certificate.

Manage—Configures the local certificate authority. To make configuration changes after it has been configured for the first time, disable the local certificate authority.

Local Dynamic Certificate Key Pair—Lists the RSA key pair used by client dynamic certificates.

Key-Pair Name—Specifies a defined key pair.

Show—Shows the key pair details, including generation time, usage, modulus size, and key data.

New—Lets you define a new key pair.

  • More Options—Specifies the available and active algorithms to be announced or matched during the TLS handshake.

Available Algorithms—Lists the available algorithms to be announced or matched during the TLS handshake: des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, and null-sha1.

Add—Adds the selected algorithm to the active list.

Remove—Removes the selected algorithm from the active list.

Active Algorithms—Lists the active algorithms to be announced or matched during the TLS handshake: des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, and null-sha1. For client proxy (acting as a TLS client to the server), the user-defined algorithms replace the original ones from the hello message for asymmetric encryption method between the two TLS legs. For example, the leg between the proxy and CallManager may be NULL cipher to offload the CallManager.

Move Up—Moves an algorithm up in the list.

Move Down—Moves an algorithm down in the list.

 

Monitoring the TLS Proxy

You can enable TLS proxy debug flags along with SSL syslogs to debug TLS proxy connection problems. For example, using the following commands to enable TLS proxy-related debug and syslog output only:

ciscoasa(config)# debug inspect tls-proxy events
ciscoasa(config)# debug inspect tls-proxy errors
ciscoasa(config)# logging enable
ciscoasa(config)# logging timestamp
ciscoasa(config)# logging list loglist message 711001
ciscoasa(config)# logging list loglist message 725001-725014
ciscoasa(config)# logging list loglist message 717001-717038
ciscoasa(config)# logging buffer-size 1000000
ciscoasa(config)# logging buffered loglist
ciscoasa(config)# logging debug-trace
 

The following is sample output reflecting a successful TLS proxy session setup for a SIP phone:

ciscoasa(config)# show log
 
Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with client outside:133.9.0.218/49159 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Set up proxy for Client outside:133.9.0.218/49159 <-> Server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Using trust point 'local_ccm' with the Client, RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Waiting for SSL handshake from Client outside:133.9.0.218/49159.
Apr 17 2007 23:13:47: %ASA-7-725010: Device supports the following 4 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : RC4-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[3] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[4] : DES-CBC3-SHA
Apr 17 2007 23:13:47: %ASA-7-725008: SSL client outside:133.9.0.218/49159 proposes the following 2 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725012: Device chooses cipher : AES128-SHA for the SSL session with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-7-725014: SSL lib error. Function: SSL23_READ Reason: ssl handshake failure
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 01, subject name: cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-7-717030: Found a suitable trustpoint _internal_ejw-sv-2_cn=CAPF-08a91c01 to validate certificate.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated. serial number: 01, subject name: cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with server inside:195.168.2.201/5061 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-725009: Device proposes the following 2 cipher(s) to server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Generating LDC for client 'cn=SEP0017593F50A8', key-pair 'phone_common', issuer 'LOCAL-CA-SERVER', RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Started SSL handshake with Server
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Client
Apr 17 2007 23:13:47: %ASA-7-725013: SSL Server inside:195.168.2.201/5061 choose cipher : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated. Certificate is resident and trusted, serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with revocation status check.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Server
 

Use the show tls-proxy commands with different options to check the active TLS proxy sessions. The following are some sample outputs:

ciscoasa(config-tlsp)# show tls-proxy
Maximum number of sessions: 1200
 
TLS-Proxy 'sip_proxy': ref_cnt 1, seq# 3
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: LOCAL-CA-SERVER
Local dynamic certificate key-pair: phone_common
Cipher suite: aes128-sha1 aes256-sha1
Run-time proxies:
Proxy 0xcbae1538: Class-map: sip_ssl, Inspect: sip
Active sess 1, most sess 3, byte 3456043
 
TLS-Proxy 'proxy': ref_cnt 1, seq# 1
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: ldc_signer
Local dynamic certificate key-pair: phone_common
Cipher-suite: <unconfigured>
Run-time proxies:
Proxy 0xcbadf720: Class-map: skinny_ssl, Inspect: skinny
Active sess 1, most sess 1, byte 42916
 
ciscoasa(config-tlsp)# show tls-proxy session count
2 in use, 4 most used
 
ciscoasa(config-tlsp)# show tls-proxy session
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786
 
ciscoasa(config-tlsp)# show tls-proxy session detail
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
Client: State SSLOK Cipher AES128-SHA Ch 0xca55e498 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK Cipher AES128-SHA Ch 0xca55e478 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 29
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=TLS-Proxy-Signer
Subject Name:
cn=SEP0002B9EB0AAD
o=Cisco Systems Inc
c=US
Validity Date:
start date: 09:25:41 PDT Apr 16 2007
end date: 09:25:41 PDT Apr 15 2008
Associated Trustpoints:
 
outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786
Client: State SSLOK Cipher AES128-SHA Ch 0xca55e398 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK Cipher AES128-SHA Ch 0xca55e378 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 2b
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=F1-ASA.default.domain.invalid
Subject Name:
cn=SEP0017593F50A8
Validity Date:
start date: 23:13:47 PDT Apr 16 2007
end date: 23:13:47 PDT Apr 15 2008
Associated Trustpoints:
 

Feature History for the TLS Proxy for Encrypted Voice Inspection

Table 4-1 lists the release history for this feature.

 

Table 4-1 Feature History for Cisco Phone Proxy

Feature Name
Releases
Feature Information

TLS Proxy

8.0(2)

The TLS proxy feature was introduced.

SIP, SCCP, and TLS Proxy support for IPv6

9.3(1)

You can now inspect IPv6 traffic when using SIP, SCCP, and TLS Proxy (using SIP or SCCP).

We did not modify any commands.

We did not modify any ASDM screens.

Support for Cisco Unified Communications Manager 8.6

9.3(1)

The ASA now interoperates with Cisco Unified Communications Manager Version 8.6 (including SCCPv21 support).

We did not modify any commands.

We did not modify any ASDM screens.