Guest

Cisco TelePresence MCU 4200 Series

How client certificates are processed to verify HTTPS and SIP TLS connections

How do the Cisco TelePresence conferencing infrastructure products process client certificates to verify HTTPS and SIP TLS connections?

This article applies to the following products:

  • Cisco TelePresence MCU 4200 Series (version 4.4)
  • Cisco TelePresence MCU 4500 Series (version 4.4)
  • Cisco TelePresence MCU 5300 Series (version 4.4)
  • Cisco TelePresence MCU MSE Series (version 4.4)
  • Cisco TelePresence ISDN Gateway (version 2.2)
  • Cisco TelePresence Supervisor MSE 8050 (version 2.3)

Background

The products listed above can perform mutual authentication with clients using digital certificates. To be able to do so, the products must contain a local certificate to present to the clients and a trust store for verifying certificates presented by the clients. The products may use different trust stores for verifying SIP TLS connections and HTTPS connections.

This article explains the mechanism used by the listed products to verify the client certificates for each of those connection types. It also provides some specific advice on how to configure your device's local certificate to ensure that encrypted SIP calls are possible.

SIP TLS

The Verification settings value determines when the device requests and tries to verify a certificate from the client. In the SIP trust store of the device:

  • If Verification settings is set to Outgoing calls only, the device requests a certificate for each TLS connection used by the call made out to the SIP entity.
  • If Verification settings is set to Outgoing and incoming calls, the device requests a certificate for all SIP TLS connections.

When a certificate is requested, the device attempts to verify it against its SIP trust store. If the client's certificate has been signed by an authority that is recorded in the trust store, the certificate is considered valid and the connection is allowed. Additionally, before sending each request the device verifies that the certificate contains a valid identity for the domain to which the request is addressed. The rules for this are as follows (see 'Further reading' links below for details):

  1. If a subjectAltName (Subject Alternative Name) extension is present in the received certificate, then:
    1. If one or more URIs that contain a SIP URI without a username portion are present, the device checks these URIs for a matching domain identity or IP address (e.g. URI = sip:vcs1.test.example or URI = sip:[2001:DB8:0:ABCD::1] or URI = sip:192.0.2.1)
    2. Otherwise, the device checks all DNS names for a matching domain identity or IP address (e.g. DNS = 192.0.2.1, DNS = vcs1.test.example, or DNS = [2001:DB8:0:ABCD::1]). Note: a wild card is not allowed in the domain identity for SIP TLS.
  2. Otherwise, if the subjectAltName extension is absent from the received certificate:

  3. The device checks the certificate's CN (Common Name). A DNS name is allowed e.g. CN = vcs1.test.example but an IP address is not allowed.

HTTP TLS

You can configure the device to verify client certificates, which applies when the client initiates the connection:

  • For differing levels of security when users log in to the web interface, the device's Client certificate security setting is configured to Verify Certificate, Certificate based authentication allowed or Certificate based authentication required.
  • For securing calls from clients of the device's API, which will typically be management products such as Cisco TelePresence Management Suite (TMS).

In each of the above cases, the device requests a certificate from the client and attempts to verify it against its HTTPS trust store. If the client's certificate has been signed by an authority that is recorded in the trust store, the certificate is considered valid and the connection is allowed.

You can also configure the device to verify servers' certificates for cases where the device initiates HTTPS communications:

  • For securing the connection to a feedback receiver before publication of feedback events (this will typically be a management product such as TMS).
  • For securing the connection to an OCSP server before checking the revocation status of a client's leaf certificate.

In each of the above cases, the device requests a certificate from the server and must verify the certificate before allowing the connection.

In all of the scenarios described above, the device processes the received certificate according to the following rules:

  1. If a subjectAltName (Subject Alternative Name) is present in the received certificate:
    1. The device checks for an IP address (e.g. IP Address = 192.0.2.1 or IP Address = 2001:DB8:0:ABCD::1)
    2. The device checks for a DNS name (e.g. DNS Name = vcs1.test.example or DNS Name = *.test.example). Note: a wild card is allowed in the DNS hostname for HTTP TLS.
  2. Otherwise, if subjectAltName is absent from the received certificate:

  3. The device checks the certificate's CN (Common Name). A DNS name is allowed e.g. CN = vcs1.test.example but an IP address is not allowed.

Further reading

  • RFC 2818 (HTTP Over TLS)
  • RFC 5922 (Domain Certificates in the Session Initiation Protocol (SIP))

May 13th, 2013 TAA_KB_697