Cisco CUBE line-side SIP proxy – Security


Two basic concepts need to be considered with the CUBE line-side feature. Access side and core side. We will continue those two concepts when we move to the follow-up posts on dial peers and SIP/RTP modifications.

Access side (aka line-side) is your connection between CUBE and the IP Phone. If your phones are already secured by another method then you could support the access side via SIP and RTP. If you’re bringing phones in from the Internet obviously you’ll want SIPS and SRTP. If you’ve ever used Wireshark to capture an RTP session it is extremely easy to listen to that voice call if the media is sent in the clear. In short – you want secure access side.

The core side is your connection between CUBE and Communications Manager. If based on your network architecture you have CUBE behind an external Internet facing firewall you may want to have a non-secure core side. Meaning SIP/RTP is sent in the clear back to CUCM and other devices internal to the network. If you have a mixed-mode cluster obviously you already have secure core and will require the “access-secure” within the phone proxy configuration.

Do you have a mixed mode cluster or a non-secure cluster? You need all of the certificates on CUBE regardless and I’ll go ahead to give some more information for LSC certificates and non-secure clusters. If you have a mixed mode cluster you’ll need to import the MIC Cisco_Manufacturing_CA, CAP-RTP-001 and CAP-RTP-002. The reason is you want valid trust points across the CUBE. If you have used USB keys or a signed CA you’ll obviously need to add those certificates to CUBE. The MIC certificates do not need to be in the CTL file. I may point this out several times but if you are doing secure core side back to CUCM you need to import the CUBE selfsigned certificate into CUCM nodes to support the SIPS/SRTP negotiation!

Similar to the ASA phone proxy in order for Cisco IP phones to download the LSC certificates, the Cisco CUBE permits the CAPF TLS connection. It does not proxy the CAPF connection. The Cisco CUBE requires the CAPF CA certificate, contained in the CTL file, for the Cisco IP phone to establish a TLS connection with the CAPF process running on the CUCM node. Once completed, Cisco IP phones can download the LSC over the CAPF TLS connection. To clarify, the USB tokens or CA certs in the CTL are not necessary because the Cisco CUBE is serving the CTL file and inserts the CAPF CA certificate, which the Cisco IP phone trusts, to establish the CAPF TLS connection. This is part of the phone proxy configuration when you do a service map for port 3804 the CAPF service on CUCM.


The phone can then dynamically update the LSC certificate from CUCM CAPF service and CUBE access line-side feature must import the CUCM CAPF certificate into the CTL to support this function.

So there are 2 purposes here to import the CAPF certificate from CUCM

#1 The phone must have this certificate in the CTL file to pass the authenticate during an LSC update

#2 CUBE would use this certificate to authenticate phone during the TLS connection.


To state the obvious for clarity – Regardless if you have a mixed-mode or non-secure cluster you obviously need to import the CAPF.pem to CUBE line-side from every CUCM node! IF you have a mixed-mode (secure) cluster you also need to import the CUBE self-signed certificate into CUCM to support the core side SIPS/SRTP negotiation. The CUBE self-signed must be imported to CUCM first. Multiple SAN certificate for the phone must be configured based on the phones security profile in CUCM. You have probably already dealt with this if you are running a mixed-mode cluster and performing SRTP with another CUBE possibly for PSTN access.

((I really want to call this out – More and more you’re going to be working with certificates across all of the Cisco Collaboration products. Do yourself a favor and have your Microsoft team spin up a Windows Server 2012 running SCEP/NDES. This way you can automatically enroll devices with a trusted CA and stop having to import/export trusted CA certificates everywhere. I’ve covered this in some older posts but it’s time to have a trusted CA across your internal corporate network.))

There is another interesting detail for CUBE on your ISR 29xx or 39xx series router. To do RTP to SRTP interworking you need DSP resources. Shocked? Don’t be. I’m getting to that configuration right now because this is super important when you pick a router for CUBE line-side. The most basic way to check if you’re already configured is via “show call active voice brief” and look for “SRTP: on” or “SRTP: off”. If you can make calls and you have NOT set up a SCCP based DSP transcoder your calls are in the clear! SRTP is controlled by your dial-peer and the “srtp” command. Setting “srtp fallback” will allow RTP media if the TLS/SRTP connection cannot be established.

Using DSP calculator I came up with this assuming G711 between IP Phone and everything else:

0-16 Sessions = PVDM3-16; 17-24 sessions = PVDM3-32; 25-48 sessions = PVDM3-64; 49-96 sessions = PVDM3-128; 97-144 sessions = PVDM3-192; 145-192 sessions = PVDM3-256. Some model routers obviously support more than one PVDM3. Use the Cisco DSP calculator for the best answer.

If you assume high complexity G729 a PVDM3-256 can only support 60 sessions!

SRTP-RTP internetworking is available with normal and universal transcoders. The transcoder on the CUBE is invoked using SCCP messaging between the SCCP server and the SCCP client. The SCCP messages carry the SRTP keys to the digital signal processor (DSP) farm at the SCCP client. The transcoder can be within the same router or can be located in a separate router. TLS should be disabled only when the transcoder is located in the same router. To disable TLS, configure the no form of the tls command in dsp farm profile configuration mode. Disabling TLS improves CPU performance since you are not needing to exchange keys within the same router. If bouncing the call off an external DSP farm you’ll need to keep TLS in the mix to ensure end-to-end secure connections.

REALLY IMPORTANT – Most companies have multiple CUCM servers for redundancy. If you want CUBE to have a redundant core side configuration you must also import the Callmanager.pem and CAPF.pem certificates from all nodes the CUBE will connect to. This is really where CUCM 10.5 can help out with multi-node multi-SAN certificates but you DON’T WANT TO USE 10.5 MULTI-SAN certificates for Callmanager.pem. I believe I was the first to find and create the SEV2 bug CSCup28852 and your phones will continually reboot due to CUCM sending group restarts to ALL phones. First fixed in 10.5(1.98000.77) but that release isn’t available yet for download.


Cisco Communications Manager 10.5 Certificates BUG

Finally we get cluster-wide certificate management via multi-SAN certificate support. EDIT 6/10/2014 – and I immediately find a SEV2 bug working with TAC Bug ID:CSCup28852. Callmanager hates this certificate and sends group resets every ITL refresh meaning your phones reboot every 10 minutes or so. Fixed in a later CUCM version but not available for download at this time.

You need to properly set up your Microsoft CA to provide the proper certificate template.

  1. New Certificate template “Web Server X509v3”
    1. Certificate purposes – Server authentication, client authentication, IP security end system
    2. Key usage – Digital signature, Non repudiation (I add this so this can also be used for the VMware hosts, Key encipherment, data encryption. When you are in “Key Usage” you cannot assign Key Agreement and Key Encryption. You want to select “key encipherment”
    3. Key length: 2048
    4. Hash: SHA256
  2. Generate Multi-SAN certificate request from your CUCM publisher
    1. Certificate purpose: tomcat
    2. Distribution: Multi-server (SAN)
    3. Common name: Can be left as-is of put in a vanity name
      1. Auto-populated Domains
      2. This should list all of your CUCM and IM&P nodes in the cluster.
    4. Parent domain!
      1. Be sure this is the parent DNS domain your SERVERS are residing in. There are some caveats here if you have servers in different domains
      2. Example:
    5. Other domains!
      1. ADD your directory URI domains (AKA e-mail domain).
      2. Example:
    6. Key Length: 2048
    7. Hash: SHA265
  3. Submit the CSR to the Microsoft CA via http://ca-server/certsrv
  4. Upload the CA root and any intermediates
  5. Upload the new certificate to CUCM publisher

Enjoy that you didn’t have to do that on every cluster node!

Reminder: If Jabber is connecting to Voicemail you need to go to Unity Connection and create CSR and assign a certificate for each Unity Connection node. Jabber will still prompt for a certificate error if Unity Connection is un-signed.