On-Premises Servers
Review which certificates on-premises servers present to the client and the tasks involved in getting those certificates signed.
Required Certificates for On-Premises Servers
Server |
Certificate |
---|---|
Cisco Unified Communications Manager IM and Presence Service |
HTTP (Tomcat) XMPP |
Cisco Unified Communications Manager |
HTTP (Tomcat) and CallManager certificate (secure SIP call signaling for secure phone) |
Cisco Unity Connection |
HTTP (Tomcat) |
Cisco Webex Meetings Server |
HTTP (Tomcat) |
Cisco VCS Expressway Cisco Expressway-E |
Server certificate (used for HTTP, XMPP, and SIP call signaling) |
Important Notes
-
Security Assertion Markup Language (SAML) single sign-on (SSO) and the Identity Provider (IdP) require an X.509 certificate.
-
You should apply the most recent Service Update (SU) for Cisco Unified Communications Manager IM and Presence Service before you begin the certificate signing process.
-
The required certificates apply to all server versions.
-
Each cluster node, subscriber, and publisher, 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.
Get Certificates Signed by Certificate Authority
-
Public CA — A third-party company verifies the server identity and issues a trusted certificate.
-
Private CA — 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:
Procedure
Step 1 |
Generate a Certificate Signing Request (CSR) on each server that can present a certificate to the client. |
Step 2 |
Submit each CSR to the CA. If the process your company uses means you must wait for the CSRs to be sent back to you before you can apply them, then you may wish to configure your services now while you wait for the CSRs. Then you can apply the certificates after the service configuration is complete, prior to deployment. |
Step 3 |
Upload the certificates that the CA issues to each server. |
Certificate Signing Request Formats and Requirements
-
Are Base64-encoded.
-
Do not contain certain characters, such as @&!, in the Organization, OU, or other fields.
-
Use specific bit lengths in the server's public key.
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.
Revocation Servers
Cisco Jabber cannot connect to the Cisco Unified Communications Manager servers if the revocation server is not reachable. Also, if a certificate authority (CA) revokes a certificate, Cisco Jabber does not allow users to connect to that server.
Users are not notified of the following outcomes:
-
The certificates do not contain revocation information.
-
The revocation server cannot be reached.
-
Ensure that the CRL Distribution Point (CDP) field contains an HTTP URL to a certificate revocation list (CRL) on a revocation server.
-
Ensure that the Authority Information Access (AIA) field contains an HTTP URL for an Online Certificate Status Protocol (OCSP) server.
Server Identity in Certificates
-
A trusted authority has issued the certificate.
Note |
Public CAs generally require a fully qualified domain name (FQDN) as the server identity, not an IP address. |
Identifier Fields
-
XMPP certificates -
SubjectAltName\OtherName\xmppAddr
-
SubjectAltName\OtherName\srvName
-
SubjectAltName\dnsNames
-
Subject CN
-
-
HTTP certificates -
SubjectAltName\dnsNames
-
Subject CN
-
Tip |
The Subject CN field can contain a wildcard (*) as the leftmost character, for example, *.cisco.com. |
Prevent Identity Mismatch
If users attempt to connect to a server with an IP address or hostname, 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 in many places on your servers. For more information, see Prevent Identity Mismatch section in Troubleshooting TechNotes.
Provide XMPP Domain to Clients
This task is not required if you are using Cisco Unified Communications Manager IM and Presence Service version 10.0 or later.
The client identifies XMPP certificates using the XMPP domain, rather than the 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:
Procedure
Step 1 |
Open the administration interface for your presence server, as follows:
|
Step 2 |
Select . |
Step 3 |
Locate the XMPP Certificate Settings section. |
Step 4 |
Specify the presence server domain in the following field: Domain name for XMPP Server-to-Server Certificate Subject Alternative Name. |
Step 5 |
Select the following checkbox: Use Domain Name for XMPP Certificate Subject Alternative Name. |
Step 6 |
Click Save. |
Import Root Certificates on Client Computers
Every server certificate should have an associated root certificate present in the trust store on client computers. Cisco Jabber validates the certificates that servers present against the root certificates in the trust store.
If you get server certificates signed by a public CA, the public CA should already have a root certificate present in the trust store on the client computer. In this case, you do not need to import root certificates on the client computers.
-
The certificates are signed by a CA that does not already exist in the trust store, such as a private CA.
- Import the private CA certificate to the Trusted Root Certification Authorities store.
-
The certificates are self-signed.
- Import self-signed certificates to the Enterprise Trust store.
Important |
If root certificates are not present in the trust store, Cisco Jabber prompts users to accept certificates from each server in your environment.
|
When users restart the client, it prompts them to accept the certificate again.
You can use any appropriate method to import certificates into the Microsoft Windows certificate store, including the following. For detailed instructions on importing certificates, refer to the appropriate Microsoft documentation.
Procedure
Deploy Certificates on Client Computers
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.
Important |
If root certificates are not present in the Keychain, Cisco Jabber prompts users to accept certificates from each server in your environment. |
-
Always trust server name — The client saves the certificate to the Keychain.
-
Continue — The client will connect, but when the user restarts the client they are prompted to accept the certificate again.
-
Cancel — The client: -
Does not save the certificate.
-
Does not connect to the server.
-
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.
Procedure
Step 1 |
For each Cisco node, download the corresponding "tomcat-trust" certificate from the Cisco Unified OS Administration interface. Select . |
||
Step 2 |
Concatenate the certificates into a single file with the extension .pem (for example, "companyABCcertificates.pem"). |
||
Step 3 |
Send the file to your Cisco Jabber users and ask them to double-click it. Doing so launches the Keychain Access application and imports the certificates.
|