Though there are no specific requirements relating to certificate providers, using certificates signed by a public certificate authority (CA), though costly, will be less intrusive to users. Certain public certificate providers now offer multi-SAN or Unified Communications Certificates (UC certs) which are advantageous for Jabber MRA because they allow for the identification of multiple servers in the same certificate. Since most public CAs are trusted by most of today’s current operating systems, any certificates signed by those CAs will be trusted as well.
Public CAs such as DigiCert allow for unlimited certificates to be created for a predefined quantity of servers using Common and Subject Alternative Names. Other providers such as Go Daddy allow for the creation of only one certificate requiring the sharing of a private key file on multiple servers. At the time of publication of this document, Cisco did not support importing of private keys on Unified Communications 10.5 or older servers, therefore it is recommended to either use DigiCert as a certificate provider (provider), or use an internal Microsoft certificate authority.
Using an internal Microsoft CA, while having no cost, requires the internal root certificate be installed as a trusted certificate on each device, otherwise users will receive untrusted certificate prompts each time they login. Installing the root certificate on end user devices can be extremely complicated and time consuming.
A couple of quick comments about the certificates:
- When considering a UC cert provider, evaluate the pricing structure, quantity of servers supported, ease of management/changes, private key requirements, trusted status/reputation of the CA, impact of changes on previously issued multi-SAN certs, etc.
- When purchasing a UC cert, you must identify the quantity of servers (FQDNs) to include in the UC cert. This will include any Cisco Unified Communications servers (primary, secondaries, tertiaries, etc) such as CUCM, CUC, IM&P, as well as Expressway servers, Expressway cluster names (if clustering is used), external FDQNs or CNAMEs associated to the Expressway server, and a “collab-edge” SAN for the external domain. It’s important to account for each of these and to include all of these in the SAN field as adding/removing entries at a later time will likely trigger revocation of any previously issued certificates.
- When purchasing your certificate, you may prompted to submit the first Certificate Signing Request at the time of order.
- Certificate Common Name and Subject Alternative Name entries are case sensitive when evaluated by Cisco UC servers. If any of the server names are mixed case, ensure the CN and/or SAN entries match the case format of the name of the server.
- The root CA certificate and any intermediate certificates must be installed on each server prior to generating the certificate signing request on each server.
- When using an internal Microsoft CA to sign certificates, mutil-SAN certificates can be created by entering SAN data in the Attributes field such as
More info to follow shortly.