Unified Communication Cluster Setup with CA-Signed Multi-Server Subject Alternate Name Configuration Example

Introduction

This document describes how to set up a Unified Communication Cluster with the use of a Certificate Authority (CA)-Signed Multi-Server Subject Alternate Name (SAN).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Cisco Unified Communications Manager (CUCM)
• CUCM IM and Presence Version 10.5

Before you attempt this configuration, ensure these services are up and functional:

• Cisco Platform Administrative Web Service
• Cisco Tomcat service

In order to verify these services on a web interface, navigate to Cisco Unified Serviceability Page Services > Network Service > Select a server. In order to verify them on the CLI, enter the utils service list command.

If SSO is enabled in the CUCM cluster, it is required to be disabled and enabled again.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Information

In CUCM Version 10.5 and later, this trust-store Certificate Signing Request (CSR) request can include SAN and alternate domains.

1. Tomcat - CUCM and IM&P
2. Cisco CallManager - Only CUCM
3. Cisco Unified Presence-Extensible Messaging and Presence Protocol (CUP-XMPP) - Only IM&P
4. CUP-XMPP Server-to-Server (S2S) - Only IM&P

It is simpler to obtain a CA-signed certificate in this version. Only one CSR is required to be signed by CA rather than the requirement to obtain a CSR from each server node and then obtain a CA-signed certificate for each CSR and manage them individually.

Configure

Step 1.

Log into Publisher's Operating System (OS) Administration and navigate to Security > Certificate Management > Generate CSR.

Step 2.
Select Multi-Server SAN in Distribution.

It auto-populates the SAN domains and the parent domain. 

Verify all the nodes of your cluster are listed for Tomcat: all CUCM and IM&P nodes bs for CallManager: only CUCM nodes are been listed.

Step 3.
Click generate and once the CSR is generated, verify all the nodes listed in the CSR are also displayed in the Successful CSR exported list.

In Certificate Management, the SAN Request is generated:

Step 4.

Click Download CSR then select the certificate purpose and Click Download CSR.

It is possible to use the local CA or an External CA like VeriSign in order to get the CSR (File downloaded in the previous step) signed.

This example shows configuration steps for a Microsoft Windows Server-based CA. If you are using a different CA or an external CA go to Step 5.

Log into https://<windowsserveripaddress>/certsrv/
Select Request a Certificate > Advanced Certificate Request.
Copy the content of the CSR file to the Base-64-encoded certificate request field and click Submit.

Submit the CSR request as shown here.

Step 5.

Note: Before uploading a Tomcat certificate verify SSO is disabled. In case it is enabled, SSO must be disabled and re-enabled once all the Tomcat certificate regeneration process is finished.

With the certificate signed, upload the CA certificates as tomcat-trust. First the Root certificate and then the intermediate certificate if it exists.

Step 6.

Now upload the CUCM signed certificate as Tomcat and verify all the nodes of your cluster are listed in the "Certificate upload operation successful" as shown in the image:

Multi-Server SAN is listed in Certificate Management as shown in the image:

Step 7.

Restart the Tomcat service on all nodes in the SAN list (first Publisher and then subscribers) via CLI with the command: utils service restart Cisco Tomcat.

Verify

Log into http://<fqdnofccm>:8443/ccmadmin in order to ensure that the new certificate is used.

CallManager Multi-Server SAN Certificate

A similar procedure can be followed for the CallManager certificate. In this case, the auto-populated domains are only CallManager nodes. If the Cisco CallManager service is not running, you can choose to keep it in the SAN list or remove it.

Before the CA-signed SAN certificate for CUCM, ensure that:

• The IP Phone is able to trust the Trust Verification Service (TVS). This can be verified with access to any HTTPS service from the phone. For example, if Corporate Directory access works, then it means that the phone trusts TVS service.
• Verify if the cluster is in Non-Secure Mode or Mixed Mode. 

To determine if it is Mixed-Mode cluster, choose Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure; 1 == Mixed Mode).  

Warning: If you are in a Mixed Mode Cluster before services restart, the CTL must be updated: Token or Tokenless.

After install the certificate issued by CA, the next list of services must be restarted in the nodes that are enable:

• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco TFTP
• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CallManager
• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CTIManager
• Cisco Unified Serviceability > Tools > Control Center - Network Services > Cisco Trust Verification Service

Troubleshoot

These logs should help the Cisco Technical Assistance Center identify any issues related to Multi-Server SAN CSR generation and upload of CA-Signed Certificate.

• Cisco Unified OS Platform API
• Cisco Tomcat
• IPT Platform CertMgr Logs

Known Caveats

• CSCur97909 - Uploading multiserver cert does not delete self-signed certs in DB
• CSCus47235 - CUCM 10.5.2 CN not duplicated into SAN for CSR
• CSCup28852 - phone reset every 7min due to cert update when using multi-server cert

If there is an existing Multi-Server Certificate, the regeneration is recommended in the following scenarios:

• Hostname or Domain change. When a hostname or domain change is performed the certificates are regenerated automatically as Self-Signed. To change it to a CA-Signed the steps above must be followed.
• If a new node was added to the cluster, a new CSR must be generated to include the new node.
• When a subscriber is restored and no backup was used, the node will have new Self-Signed certificates. A new CSR for the complete cluster will be required to include the subscriber. (There is an enhancement request CSCuv75957 to add this feature.)