Cisco Cisco TelePresence Video Communication Server Expressway
It uses its list of trusted Certificate Authority (CA) certificates and associated certificate revocation lists
(CRLs) to validate other devices connecting to it.
(CRLs) to validate other devices connecting to it.
It uses the Server Certificate and the Private key to provide a signed certificate to provide evidence that the
VCS is the device it says it is. This can be used with neighboring devices such as Microsoft Lync or Cisco
Unified Communications Manager, as well as administrators using the web interface.
VCS is the device it says it is. This can be used with neighboring devices such as Microsoft Lync or Cisco
Unified Communications Manager, as well as administrators using the web interface.
A certificate identifies the VCS. It contains names by which it is known and to which traffic is routed. If a
VCS is known by multiple names for these purposes, such as if it is part of a cluster, this must be
represented in the X.509 subject data, according to the guidance of RFC5922. The certificate must contain
the FQDN of both the VCS itself and of the cluster. If a certificate is shared across cluster peers, it must list
all possible peer FQDNs. The following lists show what must be included in the X.509 subject, depending on
the deployment model chosen.
VCS is known by multiple names for these purposes, such as if it is part of a cluster, this must be
represented in the X.509 subject data, according to the guidance of RFC5922. The certificate must contain
the FQDN of both the VCS itself and of the cluster. If a certificate is shared across cluster peers, it must list
all possible peer FQDNs. The following lists show what must be included in the X.509 subject, depending on
the deployment model chosen.
If the VCS is not clustered:
n
Subject Common Name = FQDN of VCS
n
Subject Alternate Names = leave blank
If the VCS is clustered, with individual certificates per VCS:
n
Subject Common Name = FQDN of VCS
n
Subject Alternate Names = FQDN of VCS, FQDN of cluster
If the VCS is clustered, with a single certificate per cluster:
n
Subject Common Name = FQDN of cluster
n
Subject Alternate Names = FQDN of cluster, FQDN of VCS peer 1, …. FQDN of VCS peer n
Certificate generation overview
X.509 certificates may be supplied from a third party, or may be generated by a certificate generator such as
OpenSSL or a tool available in applications such as Microsoft Office Communications Server (OCS). Third-
party certificates supplied by recognized certificate authorities are recommended, although VCS
deployments in controlled or test environments can use internally generated certificates.
OpenSSL or a tool available in applications such as Microsoft Office Communications Server (OCS). Third-
party certificates supplied by recognized certificate authorities are recommended, although VCS
deployments in controlled or test environments can use internally generated certificates.
Certificate generation is usually a 3-stage process:
n
Stage 1: generate a private key
n
Stage 2: create a certificate request
n
Stage 3: authorize and create the certificate
This document presents alternative methods of generating the root certificate, client/server certificate for the
VCS, and private key:
VCS, and private key:
n
describes how to use the VCS itself to generate the
private key and certificate request.
n
documents the OpenSSL-only process,
which could be used with a third party or internally managed CA.
For mutual TLS authentication the VCS Server certificate must be capable of being used as a Client
certificate as well, thus allowing the VCS to authenticate as a client device to a neighboring server (see
certificate as well, thus allowing the VCS to authenticate as a client device to a neighboring server (see
).
Certificate Creation and Use With Cisco VCS Deployment Guide (X7.2)
Page 4 of 36
Introduction