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 document describes how to configure the Cisco Unified Contact Center Express (UCCX) for the use of self-signed and signed certificates.
Before you proceed with the configuration steps that are described in this document, ensure that you have access to the Operating System (OS) Administration page for these applications:
An administrator can also have access to the certificate store on the agent and supervisor client PCs.
It is required that all servers in the UCCX configuration be installed with Domain Name System (DNS) servers and domain names. It is also required that agents, supervisors, and administrators access the UCCX configuration applications via the Fully Qualified Domain Name (FQDN).
If the domain changes or is populated for the first time, the certificates can be regenerated. After you add the domain name to the server configuration, regenerate all of the Tomcat certificates before you install them on the other applications, in the client browsers, or upon generation of the Certificate Signing Request (CSR) for signing.
The information described in this document is based on these hardware and software components:
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, ensure that you understand the potential impact of any command.
With the introduction of co-resident Finesse and CUIC, the integration between UCCX and SocialMiner for email and chat, and the use of MediaSense in order to record, understand, and install certificates via Finesse, the ability to troubleshoot certificate issues is now critically important.
This document describes the use of both self-signed and signed certificates in the UCCX configuration environment that covers:
Certificates, either signed or self-signed, must be installed on both the applications (servers) in the UCCX configuration, as well as the agent and supervisor client desktops.
Multi-SAN support was added in UCCX starting in version, 11.6.2.
Publically, signed CA certs on SomicalMiner/CCP is required for external chat to function over the internet.
This section describes how to configure the UCCX for the use of self-signed and signed certificates.
The recommended method of certificate management for the UCCX configuration is to leverage signed certificates. These certificates can either be signed by an internal Certificate Authority (CA) or a well-known third-party CA.
In major browsers, such as Mozilla Firefox and Microsoft Edge, root certificates for well-known third-party CAs are installed by default. The certificates for UCCX configuration applications that are signed by these CAs are trusted by default, as their certificate chain ends in a root certificate that is already installed in the browser.
The root certificate of an internal CA can also be preinstalled in the client browser through a Group Policy or other current configuration.
You can choose whether to have the UCCX configuration application certificates signed by a well-known third-party CA, or by an internal CA based on the availability and preinstallation of the root certificate for the CAs in the client browser.
Complete these steps for each node of the UCCX Publisher and Subscriber, SocialMiner, and MediaSense Publisher and Subscriber Administration applications:
Send the new CSR to the third-party CA or sign it with an internal CA, as previously described. This process can produce these signed certificates:
Note: Leave the Distribution field in the CSR as the FQDN of the server.
Note: Multi-server (SAN) certificate is supported for UCCX from 11.6 release onwards. However, the SAN can include UCCX Node-1 and Node-2 only. Other servers, such as SocialMiner, cannot be included in the SAN of UCCX. See bottom of page for CUCM SAN example which is also valid for UCCX.
Note: UCCX only supports certificate key lengths of 1024 and 2048 bits.
Complete these steps on each application server in order to upload the root certificate and application certificate to the nodes:
Note: If you upload the root and intermediate certificates on a publisher (UCCX or MediaSense), it can automatically be replicated to the subscriber. There is no need to upload the root or intermediate certificates onto the other, non-publisher servers in the configuration if all of the application certificates are signed via the same certificate chain.
Note: If a subordinate CA signs the certificate, upload the root certificate of the subordinate CA as the tomcat-trust certificate instead of the root certificate. If an intermediate certificate is issued, upload this certificate to the tomcat-trust store in addition to the application certificate.
Note: When you use UCCX and SocialMiner 11.5, there is a new certificate called tomcat-ECDSA. When you upload a signed tomcat-ECDSA certificate to the server, upload the application certificate as a tomcat-ECDSA certificate-not a tomcat certificate. For further information on ECDSA, refer to the Related Information Section for the link to understand and configure ECDSA certificates. Starting from 11.6, use of ECDSA certificates has been removed from the UCCX solution completely. This includes UCCX, SM/CCP, CUIC and Finesse.
All certificates that are used in the UCCX configuration come preinstalled on the configuration applications and are self-signed. These self-signed certificates are not implicitly trusted when presented to either a client browser or another configuration application. Although it is recommended to sign all certificates in the UCCX configuration, you can use the preinstalled self-signed certificates.
For each application relationship, you must download the appropriate certificate and upload it to the application. Complete these steps in order to obtain and upload the certificates:
In order to install self-signed certificates on the client machine, use a group policy or package manager, or install them individually in the browser of each agent PC.
For Microsoft Edge, install the client-side self-signed certificates into the Trusted Root Certification Authorities store.
For Mozilla Firefox, complete these steps:
In the case that self-signed certificates expire, they need to be regenerated, and the configuration steps from Installing On Peripheral Servers needs to be performed again.
The UCCX consumes the SocialMiner REST and Notification APIs in order to manage email contacts and configuration. Both of the UCCX nodes must consume the SocialMiner REST API and be notified by the SocialMiner notification service, so install the SocialMiner Tomcat certificate on both of the UCCX nodes.
Upload the signed or self-signed certificate chain of the SocialMiner server to the UCCX tomcat-trust keystore.
Upload the UCCX tomcat certificate from Publisher and Subscriber nodes to the SocialMiner server as tomcat-trust keystore.
The UCCX AppAdmin client certificate is used for administration of the UCCX system. In order to install the UCCX AppAdmin certificate for UCCX administrators, on the client PC, navigate to https://<UCCX FQDN>/appadmin/main for each of the UCCX nodes and install the certificate through the browser.
The UCCX web services are used for delivery of chat contacts to client browsers. In order to install the UCCX Platform certificate for UCCX agents and supervisors, on the client PC, navigate to https://<UCCX FQDN>/appadmin/main for each of the UCCX nodes and install the certificate through the browser.
The CCX Notification Service is used by Finesse, UCCX, and CUIC in order to send real-time information to the client desktop via Extensible Messaging and Presence Protocol (XMPP). This is used for real-time Finesse communication as well as CUIC Live Data.
In order to install the Notification Service client certificate on the PC of the agents and supervisors or reporting users that use Live Data, navigate to https://<UCCX FQDN>:7443/ for each of the UCCX nodes and install the certificate through the browser.
The Finesse client certificate is used by the Finesse desktops in order to connect to the Finesse Tomcat instance for the purposes of REST API communication between the desktop and the co-resident Finesse server.
In order to install the Finesse certificate for agents and supervisors, on the client PC, navigate to https://<UCCX FQDN>:8445/ for each of the UCCX nodes and install the certificate through the browser prompts.
In order to install the Finesse certificate for Finesse administrators, on the client PC, navigate to https://<UCCX FQDN>:8445/cfadmin for each of the UCCX nodes and install the certificate through the browser prompts.
The SocialMiner Tomcat certificate must be installed on the client machine. Once an agent accepts a chat request, the Chat gadget is redirected to a URL that represents the chat room. This chat room is hosted by the SocialMiner server and contains the customer or chat contact.
In order to install the SocialMiner certificate in the browser, on the client PC, navigate to https://<SocialMiner FQDN>/ and install the certificate through the browser prompts.
The CUIC Tomcat certificate can be installed on the client machine for agents, supervisors, and reporting users who use the CUIC web interface for historical reports or Live Data reports either within the CUIC web page or within the gadgets in the desktop.
In order to install the CUIC Tomcat certificate in the browser, on the client PC, navigate to https://<UCCX FQDN>:8444/ and install the certificate through the browser prompts.
CUIC Live Data Certificate (Since 11.x)
The CUIC uses the Socket IO Service for the backend Live data. This certificate can be installed on the client machine for agents, supervisors and reporting users who use the CUIC web interface for Live Data or who use the Live Data gadgets within Finesse.
In order to install the Socket IO certificate in the browser, on the client PC, navigate to https://<UCCX FQDN>:12015/ and install the certificate through the browser prompts.
If a UCCX script is designed in order to access a secure location on a third-party server (for example, Get URL Document step to an HTTPS URL or a Make Rest Call to an HTTPS REST URL), upload the signed or self-signed certificate chain of the third-party service to the UCCX tomcat-trust keystore. In order to obtain this certificate, access the UCCX OS Administration page and choose Upload Certificate.
The UCCX Engine is configured in order to search the platform Tomcat keystore for third-party certificate chains when presented with these certificates by third-party applications when they access secure locations via script steps.
The entire certificate chain must be uploaded to the platform Tomcat keystore, accessible via the OS Administration page, as the Tomcat keystore contains no root certificates by default.
After you complete these actions, restart the Cisco UCCX Engine.
In order to verify that all of the certificates are installed correctly, you can test the features that are described in this section. If no certificate errors appear and all features function properly, the certificates are installed correctly.
UCCX Finesse Agents are unable to log in with error "Invalid User ID/Password".
Unified CCX throws an exception “SSLHandshakeException“ and fails to establish a connection with Unified CM.
The upload of a CA signed certificate displays error "CSR SAN and Certificate SAN does not match".
The CA can have added another parent domain in the certificate Subject Alternative Names (SAN) field. By default, the CSR can have these SANs:
SubjectAltName [
example.com (dNSName)
hostname.example.com (dNSName)
]
The CAs can return a certificate with another SAN added to the certificate: www.hostname.example.com. The certificate can have an extra SAN in this case:
SubjectAltName [
example.com (dNSName)
hostname.example.com (dNSName)
www.hostname.example.com (dNSName)
]
This causes the SAN mismatch error.
In the 'Subject Alternate Name (SANs)' section of the UCCX 'Generate Certificate Signing Request' page, generate the CSR with an empty Parent Domain field. This way the CSR is not generated with a SAN attribute, the CA can format the SANs, and there cannot be a SAN attribute mismatch when you upload the certificate to UCCX. Note that the Parent Domain field defaults to the domain of the UCCX server, so the value must explicitly be removed while the settings for the CSR are configured.
When you access any UCCX, MediaSense, or SocialMiner web page, you receive an error message.
"Your connection is not private.
Attackers can be trying to steal your information from <Server_FQDN> (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is <Server_FQDN>; its security certificate is from [missing_subjectAltName]. This can be caused by a misconfiguration or an attacker intercepting your connection."
Chrome version 58 introduced a new security feature where it reports that a website's certificate is not secure if its common name (CN) is not also included as a SAN.
See the section "Remove support for commonName matching in certificates" in Deprecations and Removals in Chrome 58.
Revision | Publish Date | Comments |
---|---|---|
2.0 |
20-Oct-2023 |
Added Alt Text.
Updated Title, Introduction, PII, SEO, Legal Disclaimer, Machine Translation, Style Requirements, and Formatting. |
1.0 |
24-Mar-2015 |
Initial Release |