The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter provides information about certificate management and IPsec management and provides procedures for performing related tasks.
To download certificates from the Cisco Unified Communications Manager node, ensure that your Internet Explorer security settings are configured as follows:
The following topics describe the functions that you can perform from the Certificate Management menu.
Note | To access the Security menu items, you must sign in to Cisco Unified Communications Operating System Administration again using your administrator password. |
Restart the following services after regenerating or uploading certificates:
Certificate | Services to restart |
---|---|
CUP | Cisco SIP Proxy, Cisco Presence Engine |
cup-trust | Cisco SIP Proxy, Cisco Presence Engine |
cup-xmpp | Cisco XCP Connection Manager, Cisco XCP Web Connection Manager |
cup-xmpp-s2s | Cisco XCP XMPP Federation Connection Manager |
cup-xmpp-trust | Cisco XCP Connection Manager, Cisco XCP Web Connection Manager, Cisco XCP XMPP Federation Connection Manager |
tomcat | Cisco Tomcat |
tomcat-trust | Cisco Tomcat |
To download a certificate from the Cisco Unified Communications Operating System to your PC, follow this procedure:
Unified Intelligence Center supports only one level of intermediate certificate. To install an intermediate certificate you must install a root certificate first and then upload the signed certificate.
These sections describe how to delete and regenerate a certificate.
To delete a trust certificate, follow this procedure:
Caution | Deleting a certificate can affect your system operations. Deleting this certificate permanently may break a certificate chain if this certificate is part of an existing chain. You can verify this from the username and subject name of the relevant certificates in the Certificate List window. You cannot undo this action. |
Step 1 | From the Cisco Unified Serviceability webpage, navigate to and stop the Cisco Certificate Change Notification service. |
Step 2 | Navigate to
.
The Certificate List window displays. |
Step 3 | You can use the Find controls to filter the certificate list. |
Step 4 | Click the file
name of the certificate.
The Certificate Configuration window displays. |
Step 5 | Click
Delete.
For more information about deleting a certificate, see the caution. |
Step 6 | Click OK. |
Step 7 | Restart the
Cisco Certificate Change Notification service.
The selected certificate has been permanently deleted. |
You can regenerate certificates from the Cisco Unified Communications Operating System as an operating system security function. For more information about regenerating certificates, see the Cisco Unified Communications Manager Security Guide.
Caution | Regenerating a certificate can affect your system operations. Regenerating a certificate overwrites the existing certificate including a third party signed certificate if one was uploaded. |
Note | Certificate regeneration or upload a of third party signed certificates should be performed during maintenance. |
Related Services |
||
---|---|---|
This self-signed root certificate is generated during installation for the HTTPS node. |
tomcat |
|
This self-signed root certificate is generated during installation for IPsec connections with MGCP and H.323 gateways. |
Cisco Disaster Recovery System (DRS) Local and Cisco DRF Master |
|
This self-signed root certificate is installed automatically when you install Cisco Unified Communications Manager. This certificate provides node identification, including the node name and the Global Unique Identifier (GUID). |
CallManager, CAPF, and CTI |
|
The system copies this root certificate to your node or to all nodes in the cluster after you complete the Cisco client configuration. |
CallManager and CAPF |
|
TVS |
If you regenerated the certificate for Cisco Certificate Authority Proxy Function (CAPF) or Cisco Unified Communications Manager and a CTL client is configured, rerun the CTL client.
After you regenerate certificates in the Cisco Unified Communications Operating System, you must perform a system backup so that the latest backup contains the regenerated certificates. If your backup does not contain the regenerated certificates and you perform a system restoration task, you must manually unlock each phone in your system so that the phone can register with Cisco Unified Communications Manager. For information about performing a backup, see the Disaster Recovery System Administration Guide.
Step 1 | Navigate to
.
The Certificate List window displays. |
Step 2 | Click
Generate
New.
The Generate Certificate dialog box opens. |
Step 3 | From the Certificate Name drop-down list, choose a certificate name . For details about certificate names, see the Certificate Names and Descriptions table. |
Step 4 | From the Key Length drop-down list, choose 1024 or 2048. |
Step 5 | From the Hash Algorithm drop-down list, choose SHA1 or SHA256. |
Step 6 | Click Generate New. |
Restart all services that are affected by the regenerated certificate as listed in the Certificate Names and Descriptions table.
Rerun the CTL client (if configured) after you regenerate the CAPF or CallManager certificates.
Perform a system backup to capture the newly regenerated certificates. For information about performing a backup, see the Disaster Recovery System Administration Guide.
Command or Action | Purpose |
---|
Caution | Uploading a new certificate can affect your system operations. After you upload a new certificate or certificate trust list, you must restart the Cisco Unified Communications Manager service by navigating to . For more information, see the Cisco Unified Serviceability Administration Guide. |
The following sections describe how to upload a Certificate Authority (CA) root certificate and application certificate to the node.
Note | You can upload the certificate or certificate chain to Certificate Trust or for a third-party signed certificate. |
Step 1 | Navigate to . |
Step 2 | The Certificate
List window displays.
Click Upload Certificate/Certificate Chain. The Upload Certificate/Certificate Chain dialog box opens. |
Step 3 | Select the certificate name from the Certificate Name list. |
Step 4 | Select the file
to upload by doing one of the following steps:
|
Step 5 | To upload the file to the server, click the Upload File button. |
Cisco Unified Communications Operating System supports certificates that a third-party CA issues with PKCS#10 Certificate Signing Request (CSR).
Note | Cisco Unified Communications Manager supports SHA1 signed certificates exclusively. |
The following table provides an overview of this process, with references to additional documentation:
Step 1 | Generate a CSR on the server. | ||
Step 2 | Download the CSR to your PC. | ||
Step 3 | Use the CSR to obtain an application certificate from a CA or PKCS#7 format certificate chain, which may contain application certificate along with CA certificate. Get information about obtaining a root certificate from your CA. | ||
Step 4 | Obtain the CA certificate or certificate chain. Get information about obtaining a root certificate from your CA. | ||
Step 5 | Upload third-party certificate. | ||
Step 6 | If you updated
the certificate for CAPF or
Cisco Unified Communications
Manager, generate a new CTL (Certificate Trust List) file.
See the Cisco Unified Communications Manager Security Guide. Rerun CTL client (if configured) after uploading third-party signed CAPF or CallManager certificate. | ||
Step 7 | Restart the
services that are affected by the new certificate.
For all certificate types, restart the corresponding service (for example, restart the Tomcat service after regenerating the Tomcat certificate). In addition, if you updated the certificate for CAPF or Cisco Unified Communications Manager, restart the Cisco Certificate Authority Proxy Function and Cisco CallManager service.
See the Cisco Unified Communications Manager Serviceability Administration Guide for information about restarting services. |
Upload the certificate authority (CA) root certificate of the CA that signed an application certificate. If a subordinate CA signs an application certificate, you must upload the CA root certificate of the subordinate CA. You can also upload the PKCS#7 format Certificate chain of all CA certificates.
You can upload CA root certificates and application certificates by using the same Upload Certificate dialog box. When you upload a CA root certificate or certificate chain that contains only CA certificates, choose the certificate name with the format certificate type-trust. When you upload an application certificate or Certificate chain that contains an application certificate and CA Certificates, choose the certificate name that includes only the certificate type.
For example, choose tomcat-trust when you upload a Tomcat CA Certificate or CA Certificate Chain; choose tomcat when you upload a Tomcat application certificate or Certificate chain that contains an application certificate and CA Certificates.
When you upload a CAPF CA root certificate, it is copied to the CallManager-trust store, so you do not need to upload the CA root certificate for CallManager separately.
Note | Successful upload of third-party CA signed certificate deletes a recently generated CSR that was used to obtain a signed certificate and overwrites the existing certificate, including a third-party signed certificate if one was uploaded. |
Note | The system automatically replicates tomcat-trust, CallManager-trust and Phone-SAST-trust certificates to each node in the cluster. |
Note | The Directory option no longer appears in the list of Certificate Names. However, you can still upload a Directory Trust certificate to tomcat-trust, which is required for the DirSync service to work in Secure mode. |
Step 1 | Navigate to
.
The Certificate List window displays. | ||
Step 2 | Click
Generate
CSR.
The Generate Certificate Signing Request dialog box opens. | ||
Step 3 | From the
Certificate Name drop-down list, choose a certificate name.
For details about certificate names, see the Certificate Names and Descriptions table. | ||
Step 4 | From the Key Length drop-down list, choose 1024 or 2048. | ||
Step 5 | From the Hash Algorithm drop-down list, choose SHA1 or SHA256. | ||
Step 6 | Click
Generate
CSR.
|
To download a Certificate Signing Request, follow this procedure:
To use an application certificate that a third-party CA issues, you must obtain both the signed application certificate and the CA root certificate from the CA or PKCS#7 Certificate Chain (DER format), which contains both the application certificate and CA certificates. Retrieve information about obtaining these certificates from your CA. The process varies among CAs.
Cisco Unified Communications Operating System generates CSRs in PEM encoding format. The system accepts certificates in DER and PEM encoding formats and PKCS#7 Certificate chain in PEM format. For all certificate types except CAPF, you must obtain and upload a CA root certificate and an application certificate on each node.
For CAPF, obtain and upload a CA root certificate and an application certificate only on the first node. CAPF and Cisco Unified Communications Manager CSRs include extensions that you must include in your request for an application certificate from the CA. If your CA does not support the ExtensionRequest mechanism, you must enable the X.509 extensions, as follows:
The CAPF CSR uses the following extensions:
X509v3 extensions:X509v3 Key Usage: Digital Signature, Key Encipherment, Certificate Sign X509v3 Extended Key Usage: TLS Web Server Authentication, IPsec End System
The CSRs for Cisco Unified Communications Manager, Tomcat, and IPsec use the following extensions:
Note | Tomcat does not require the Key Agreement or IPsec End System key usage. |
X509v3 extensions:X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, IPsec End System
Note | You can generate a certificate signing request (CSR) for your certificates and have them signed by a third party CA with a SHA256 signature. You can then uploads this signed certificate back to Unified Communications Manager, allowing for Tomcat and other certificates to be support SHA256. |
The system can automatically send you an e-mail message when a certificate is close to its expiration date. To view and configure the Certificate Expiration Monitor, follow this procedure:
Step 1 | To view the
current Certificate Expiration Monitor configuration, navigate to
.
The Certificate Monitor window displays. | ||||||||||||
Step 2 | Enter the
required configuration information. See the following table for a description
of the Certificate Monitor Expiration fields.
| ||||||||||||
Step 3 | To save your changes, click Save. |
The following topic describes the function that you can perform with the Certificate Revocation menu.
You can use the Online Certificate Status Protocol (OCSP) to obtain the revocation status of the certificate.
Step 1 | Navigate to
.
The Certificate Revocation window displays. | ||||
Step 2 | Check the Enable OCSP check box in the Online Certificate Status Protocol Configuration area. | ||||
Step 3 | Choose Use OCSP URI from Certificate if the certificate is configured with OCSP URI and that to be used to contact OCSP Responder. | ||||
Step 4 | Choose Use configured OCSP URI if external or configured URI is used to contact OCSP Responder. Enter the URI of the OCSP Responder, where certificate revocation status is verified, in the OCSP Configured URI field. | ||||
Step 5 | Check the Enable Revocation Check check box to perform the revocation check.
| ||||
Step 6 | Enter the Check Every value to check the periodicity of the certificate revocation status. | ||||
Step 7 | Click
Save.
|
If you encounter an error when attempting to access Cisco Unified Communications Manager services from an IM and Presence node or IM and Presence services from a Cisco Unified Communications Manager node, there may be a problem with the tomcat-trust certificate. The error message "Connection to the Server cannot be established (unable to connect to Remote Node)" will appear on the following Serviceability interface pages:
This procedure provides steps to help you resolve the certificate error. Start with the first step and proceed if necessary. In some cases, you may only have to complete the first step to resolve the error; in other cases, you will have to complete all steps.
Step 1 | From the Cisco
Unified OS Administration interface, verify that the required tomcat-trust
certificates are present:
.
If the required certificates are not present, wait 30 minutes before checking again. |
Step 2 | Select the certificate to obtain information about the certificate and verify that the content matches the contents of the same certificate on the remote node. |
Step 3 | From Cisco Unified Serviceability Administration, choose . |
Step 4 | Under Platform Services, choose Cisco Certificate Change Notification. |
Step 5 | Click Restart. |
Step 6 | Wait 30 minutes. If the previous steps have not addressed the certificate error and an IM and Presence tomcat-trust certificate is present, delete the certificate. After you delete the certificate, you must manually exchange it by downloading the Tomcat certificate for each node, and uploading it to its peers as a tomcat-trust certificate. After the certificate exchange is complete, restart the Cisco Certificate Change Notification service on each affected node. |
The following topics describe the functions that you can perform with the IPsec menu.
Note | IPsec is not automatically set up between nodes in the cluster during installation. |
To set up a new IPsec policy and association, follow this procedure:
Note | Because any changes that you make to an IPsec policy during a system upgrade will be lost, do not modify or create IPsec policies during an upgrade. |
Note | IPSEC requires bi-directional provisioning, one peer for each host (or gateway). |
Note | When provisioning the IPsec Policy on two Call Manager nodes with one Call Manager IPsec policy protocol set to ANY and the other Call Manager IPsec policy protocol set to UDP or TCP, the validation may result in a false negative if the validation is run from the Call Manager node using the "ANY" protocol. |
Caution | IPsec, especially with encryption, will affect the performance of your system. |
Step 1 | Navigate to
.
The IPSEC Policy List window displays. | ||||||||||||||||||||||||||||||||||||||||||||||||||
Step 2 | Click
Add
New.
The IPSEC Policy Configuration window displays. | ||||||||||||||||||||||||||||||||||||||||||||||||||
Step 3 | Enter the
appropriate information in the IPSEC Policy Configuration window. For a
description of the fields in this window, see the following table.
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Step 4 | To set up the
new IPsec policy, click
Save.
To validate the IPSEC, navigate to check the Validate IPSec check box and click Ping. This ping verifies the IPSec connection.The following table lists the field names that are displayed when the system is in Non Federal Information Processing Standard (Non FIPS) mode. The following table lists the field names that are displayed when the system is in FIPS mode.
|
When the system switches from Non FIPS to FIPS mode, the following changes occur:
If there is an existing IPsec policy that uses preshared keys authentication mode then the user has to remove this policy to move to FIPS mode.
If there is an existing IPsec policy that uses certificate authentication mode and weak Encryption Algorithm as DES then the policy is migrated to stronger cipher AES128 to become operational in FIPS mode. The user is informed about this migration in the CLI.
If there is an existing IPsec policy that uses certificate authentication mode and weak Hash Algorithm as MD5, then the policy is migrated to stronger cipher SHA1.
If there is an existing IPsec policy that uses certificate authentication mode and weak ESP Algorithm as NULL, DES, BLOWFISH 448, RJINDAEL then the policy is migrated to stronger cipher AES128.
When system switches from FIPS to Non FIPS mode, the IPsec policy does not change.
Note | The migration from FIPS to Non FIPS or vice versa causes certificate regeneration for IPsec. Therefore, after importing the remote node's regenerated certificate, the IPsec policies need to be disabled and enabled explicitly. |
Note | Compatible algorithm and authentication mode is required to set up an IPsec policy between two Non-FIPS systems or between a FIPS and a Non-FIPS system. |
Note | Compatible authentication mode is required to set up a FIPS-based IPsec policy. |
To display, enable or disable, or delete an existing IPsec policy, follow this procedure:
Note | Because any changes that you make to an IPsec policy during a system upgrade are lost, do not modify or create IPsec policies during an upgrade. |
Caution | IPsec, especially with encryption, affects the performance of your system. |
Caution | Any changes that you make to existing IPsec policies can affect your normal system operations. |
Caution | Any changes that you make to the existing IPsec certificate due to hostname/domain/IP address change would need the administrator to delete the IPsec policies and recreate IPsec policies if certificate names are changed. If certificate names are unchanged, then after importing the remote node's regenerated certificate, the IPsec policies need to be disabled and enabled explicitly. |
Note | To access the Security menu items, you must sign in to Cisco Unified Communications Operating System Administration again using your Administrator password. |
To support the Extension Mobility Cross Cluster (EMCC) feature, the system allows you to execute a bulk import and export operation to and from a common SFTP server that has been configured by the cluster administrator.
Note | If you have Cisco Unified IP Phone 8961, 9951, or 9971 Firmware Release 9.0(2) and your cluster is running in mixed mode, the Trust Certificate(s) for all clusters must be signed by a common set of security tokens in order for the EMCC feature to operate. If you manage cluster security using the Cisco CTL Client, you must have a minimum of one token that is the same among all clusters. The minimum token requirement does not apply if you manage cluster security using the CLI. |
To use Bulk Certificate Management to export certificates, use the following procedure:
Step 1 | Navigate to
.
The Bulk Certificate Management window displays. |
Step 2 | Enter the appropriate information on the Bulk Certificate Management window. |
Step 3 | To save the values you entered, click Save. |
Step 4 | To export
certificates, click
Export.
The Bulk Certificate Export popup window displays. |
Step 5 | From the drop-down menu, choose the type of certificate you want to export: |
Step 6 | Click
Export.
The system exports and stores the certificates you chose on the central SFTP server. |
You can also use the Bulk Certificate Management window to import certificates that you have exported from other clusters. However, before the Import button displays, you must complete the following activities:
Export the certificates from at least two clusters to the SFTP server.
Consolidate the exported certificates.
Enter the IP address of the common node where you want to export the certificates. |
|
Enter a directory on the node where you want to save the certificates. |
There are two types of Single Sign On (SSO): OpenAM SSO and Security Assertion Markup Language (SAML) SSO. The Cisco Unified Communications Manager Operating System interface is used to configure OpenAM SSO only. For information about SAML SSO, see the Features and Services Guide for Cisco Unified Communications Manager.
To configure OpenAM SSO, click .
Note | SSO is supported only for End User accounts, such as Agent Flow or SAML. SSO is not supported for Application User accounts. |
This application is split into three components:
A warning message displays indicating that the change in SSO settings causes Tomcat restart.
The following error messages may display when enabling the SSO application:
If you get any of the above error messages while enabling SSO, then the status changes to the above errors.
You can select or deselect the application for enabling or disabling SSO for a specific application.
The following applications are available:
The server settings are editable only when SSO is disabled for all applications.
Step 1 | Enter the
following URL of the Open Access Manager (OpenAM) server:
http://opensso.sample.com:443/opensso |
Step 2 | Enter the relative path where the policy agent should be deployed. The relative path must be alphanumeric. |
Step 3 | Enter the name of the profile that is configured for this policy agent. |
Step 4 | Enter the password of the profile name. |
Step 5 | Enter the login Module instance name that is configured for Windows Desktop SSO. |
Step 6 | Click Save. |
Step 7 | Click OK on the confirmation dialog box to restart Tomcat. |