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.
Cisco Jabber uses certificate validation to establish secure connections with servers.
When attempting to establish secure connections, servers present Cisco Jabber with certificates.
Cisco Jabber validates those certificates against certificates in the Keychain.
If the client cannot validate a certificate, it prompts the user to confirm if they want to accept the certificate.
In Expressway for Mobile and Remote Access deployment, when using an online certificate status protocol (OCSP) or online certificate revocation lists (CRL) to obtain the revocation status of the certificates, the Cisco Jabber client expects a response time of less than 5 seconds. Connections will fail if the response time is greater than the expected 5 seconds.
Review which certificates on-premises servers present to the client and the tasks involved in getting those certificates signed.
Server | Certificate |
---|---|
Cisco Unified Presence or Cisco Unified Communications Manager IM and Presence Service |
HTTP (Tomcat) XMPP |
Cisco Unified Communications Manager |
HTTP (Tomcat) |
Cisco Unity Connection |
HTTP (Tomcat) |
Cisco WebEx Meetings Server |
HTTP (Tomcat) |
Cisco VCS Expressway Cisco Expressway-E |
Server certificate (used for HTTP and XMPP) |
You should apply the most recent Service Update (SU) for Cisco Unified Presence or Cisco Unified Communications Manager IM and Presence Service before you begin the certificate signing process.
The required certificates apply to all server versions.
Each node in a cluster, subscribers and publishers, runs a Tomcat service and can present the client with an HTTP certificate.
You should plan to sign the certificates for each node in the cluster.
To secure SIP signaling between the client and Cisco Unified Communications Manager, you should use Certification Authority Proxy Function (CAPF) enrollment.
A third-party company verifies the server identity and issues a trusted certificate.
You create and manage a local CA and issue trusted certificates.
The signing process varies for each server and can vary between server versions. It is beyond the scope of this document to provide detailed steps for every version of each server. You should consult the appropriate server documentation for detailed instructions on how to get certificates signed by a CA. However, the following steps provide a high-level overview of the procedure:
To prevent issues with your CSRs, you should review the format requirements from the public CA to which you plan to submit the CSRs. You should then ensure that the information you enter when configuring your server conforms to the format that the public CA requires.
One Certificate Per FQDN: Some public CAs sign only one certificate per fully qualified domain name (FQDN).
For example, to sign the HTTP and XMPP certificates for a single Cisco Unified Communications Manager IM and Presence Service node, you might need to submit each CSR to different public CAs.
To validate certificates, the certificate must contain an HTTP URL in the CDP or AIA fields for a reachable server that can provide revocation information.
Note | Public CAs generally require a fully qualified domain name (FQDN) as the server identity, not an IP address. |
Tip | The Subject CN field can contain a wildcard (*) as the leftmost character, for example, *.cisco.com. |
If users attempt to connect to a server with an IP address, and the server certificate identifies the server with an FQDN, the client cannot identify the server as trusted and prompts the user.
If your server certificates identify the servers with FQDNs, you should plan to specify each server name as FQDN throughout your environment.
The client identifies XMPP certificates using the XMPP domain, rather than FQDN. The XMPP certificates must contain the XMPP domain in an identifier field.
When the client attempts to connect to the presence server, the presence server provides the XMPP domain to the client. The client can then validate the identity of the presence server against the XMPP certificate.
Complete the following steps to ensure the presence server provides the XMPP domain to the client:
Every server certificate should have an associated certificate in the Keychain on the client computers. Cisco Jabber validates the certificates that the servers present against the certificates in the Keychain.
If root certificates are not present in the Keychain, Cisco Jabber prompts users to accept certificates from each server in your environment.
Prevent the warning dialogs by downloading the certificates from the Cisco Unified OS Administration interface. Complete the following steps to deploy self-signed certificates to the user.
Cisco WebEx certificates are signed by a public Certificate Authority (CA). Cisco Jabber validates these certificates to establish secure connections with cloud-based services.
As of Cisco Jabber for Windows 9.7.2 and Cisco Jabber for Mac 9.6.1, Cisco Jabber validates the XMPP certificate received from Cisco WebEx Messenger. The root certificate for Cisco WebEx Messenger is the DST Root CA X3 certificate. If your operating system does not contain this certificate you must provide the root certificate.
For Cisco Jabber for Windows 9.7.2 or later, you can find more information and installation instructions for the root certificate at http://www.identrust.co.uk/certificates/trustid/install-nes36.html.
For Cisco Jabber for Mac 9.6.1 or later, you can find more information for the root certificate on the Apple support website at http://support.apple.com.
In cloud-based deployments, Cisco WebEx assigns unique URLs to profile photos when you add or import users. When Cisco Jabber resolves contact information, it retrieves the profile photo from Cisco WebEx at the URL where the photo is hosted.
The client can validate the web server that is hosting the profile photo against the Cisco WebEx certificate.
The client cannot validate the web server that is hosting the profile photo against the Cisco WebEx certificate.
In this case, the client prompts users to accept certificates whenever they look up contacts with an IP address in their profile photo URLs.
Cisco recommends that you update all profile photo URLs that contain an IP address as the server name. You should replace the IP address with the FQDN that contains the Cisco WebEx domain to ensure that the client does not prompt users to accept certificates.
When you update a photo, the photo can take up to 24 hours to refresh in Cisco Jabber.
You can complete the following steps to update profile photo URLs. Refer to the appropriate Cisco WebEx documentation for detailed instructions.