Cisco UC Integration with IBM Sametime Integration Guide 9.5(2)
Set Up Certificate Verification
Downloads: This chapterpdf (PDF - 1.14MB) The complete bookPDF (PDF - 2.44MB) | The complete bookePub (ePub - 345.0KB) | Feedback

Set Up Certificate Verification

Cisco UC Integration for IBM Sametime uses certificate validation to establish secure connections with servers.

When attempting to establish secure connections, servers present Cisco UC Integration for IBM Sametime with certificates. Cisco UC Integration for IBM Sametime validates those certificates against certificates in the Microsoft Windows certificate store. If the certificates are not present in the certificate store, the client prompts the user to confirm if they want to connect to the server.

Required Certificates

On-premises servers present the following certificates to establish a secure connection with Cisco UC Integration for IBM Sametime.

Server Type of Certificate
Cisco Unified Presence HTTP(Tomcat)

XMPP

Cisco Unified Communications Manager IM and Presence HTTP (Tomcat)

XMPP

Cisco Unified Communications Manager HTTP (Tomcat)
Cisco Unity Connection HTTP (Tomcat)
Important:
  • You should apply the most recent system upgrade (SU) for Cisco Unified Presence or Cisco Unified Communications Manager IM and Presence before you begin the certificate signing process.
  • The required certificates apply to all server versions. For example, both Cisco Unified Presence version 8.x and Cisco Unified Communications Manager IM and Presence version 9.x and higher present the client with XMPP and HTTP certificates.
  • 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.

Get Certificates Signed by Certificate Authority

Cisco recommends using server certificates that are signed by one of the following types of Certificate Authority (CA):

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. 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.
    Step 3   Upload the certificates that the CA issues to each server.

    Certificate Signing Request Formats and Requirements

    Public CAs typically require CSRs to conform to specific formats. For example, a public CA might only accept CSRs that:

    • 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.

    Likewise, if you submit CSRs from multiple nodes, public CAs might require that the information is consistent in all CSRs.

    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 HTTP and XMPP certificates for a single Cisco Unified Communications Manager IM and Presence node, you might need to submit each CSR to different public CAs.

    Server Identity in Certificates

    As part of the signing process, the CA specifies the server identity in the certificate. When the client validates that certificate, it checks that:

    • A trusted authority has issued the certificate.
    • The identity of the server that presents the certificate matches the identity of the server specified in the certificate.

    Note


    Public CAs generally require a fully qualified domain name (FQDN) as the server identity, not an IP address.

    Identifier Fields

    The client checks the following identifier fields in server certificates for an identity match:

    XMPP certificates
    • SubjectAltName\OtherName\xmpAddr
    • 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, 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.

    Provide XMPP Domain to Clients

    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:

    Procedure
      Step 1   Open the administration interface for your presence server, as follows:

      Cisco Unified Communications Manager IM and Presence

      Open the Cisco Unified CM IM and Presence Administration interface.

      Cisco Unified Presence

      Open the Cisco Unified Presence Administration interface.

      Step 2   Select Systerm > Security > Settings.
      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   Select 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 UC Integration for IBM Sametime 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.

      You should import root certificates into the Microsoft Windows certificate store if:

      • 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 UC Integration for IBM Sametime prompts users to accept certificates from each server in your environment.

      When the client prompts users to accept a certificate, users can:

      Accept the certificate

      The client saves the certificate to the Enterprise Trust store.

      Decline the certificate

      The client:

      • Does not save the certificate.
      • Does not connect to the server.
      • Displays an error notification.

      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.
      • Use the Certificate Import Wizard to import certificates individually.
      • Deploy certificates to users with the CertMgr.exe command line tool on Microsoft Windows Server.

      Note


      This option requires you to use the Certificate Manager too, CertMgr.exe, not the Certificates Microsoft Management console, CertMgr.msc.
      • Deploy certificates to users with a Group Policy object (GPO) on Microsoft Windows Server.