n
The
Chat Node Aliases
that are configured on the IM and Presence servers. These are required only for
Unified Communications XMPP federation deployments that intend to use both TLS and group chat. (Note
that Unified Communications XMPP federation will be supported in a future VCS release).
The VCS Control automatically includes the chat node aliases in the CSR, providing it has discovered a
set of IM&P servers.
n
The names, in FQDN format, of all of the
Phone Security Profiles
in Unified CM that are configured for
encrypted TLS and are used for devices requiring remote access. This ensures that Unified CM can
communicate with VCS Control via a TLS connection when it is forwarding messages from devices that
are configured with those security profiles.
A new certificate may need to be produced if chat node aliases are added or renamed, such as when an IM
and Presence node is added or renamed, or if new TLS phone security profiles are added. You must restart
the VCS Control for any new uploaded server certificate to take effect.
VCS Expressway server certificate requirements
The VCS Expressway server certificate needs to include the following elements in its list of subject alternate
names:
n
All of the domains which have been configured for Unified Communications. They are required for secure
communications between endpoint devices and VCS Expressway.
This should include the email address domain entered by users of the client application (e.g. Jabber) and
any presence domains (as configured on the VCS Control) if they are different. There is no need to include
the domains in DNS-SEC deployments.
n
The same set of
Chat Node Aliases
as entered on the VCS Control's certificate, if you are deploying
federated XMPP.
Note that the list of required aliases can be viewed (and copy-pasted) from the equivalent
Generate CSR
page on the VCS Control.
A new certificate must be produced if new presence domains or chat node aliases are added to the system.
You must restart the VCS Expressway for any new uploaded server certificate to take effect.
Managing certificate revocation lists (CRLs)
Certificate revocation list (CRL) files are used by the VCS to validate certificates presented by client
browsers and external systems that communicate with the VCS over TLS/HTTPS. A CRL identifies those
certificates that have been revoked and can no longer be used to communicate with the VCS.
We recommend that you upload CRL data for the CAs that sign TLS/HTTPS client and server certificates.
When enabled, CRL checking is applied for every CA in the chain of trust.
CRL sources
The VCS can obtain CRL information from multiple sources:
n
automatic downloads of CRL data from CRL distribution points
n
through OCSP (Online Certificate Status Protocol) responder URIs in the certificate to be checked (SIP
TLS only)
n
manual upload of CRL data
n
CRL data embedded within the VCS's
Trusted CA certificate
file
The following limitations and usage guidelines apply:
Cisco VCS Administrator Guide (X8.1.1)
Page 288 of 507
Maintenance
About security certificates