Cisco Cisco TelePresence Video Communication Server Expressway
A certificate identifies the VCS. It contains names by which it is known and to which traffic is routed. If the 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. The following lists show what must be included in the X.509 subject, depending on the
deployment model chosen.
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. 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:
■
Subject Common Name = FQDN of VCS
■
Subject Alternate Names = leave blank
If the VCS is clustered, with individual certificates per VCS:
■
Subject Common Name = FQDN of VCS
■
Subject Alternate Names = FQDN of VCS, FQDN of cluster
Wildcard certificates manage multiple subdomains and the services names they support, they can be less secure
than SAN (Subject Alternate Name) certificates. VCS does not support wildcard certificates.
than SAN (Subject Alternate Name) certificates. VCS does not support wildcard certificates.
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 Certification Authority. 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 Certification Authority. 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:
■
Stage 1: generate a private key
■
Stage 2: create a certificate request
■
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:
and private key:
■
describes how to use the VCS itself to generate the
private key and certificate request.
■
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
well, thus allowing the VCS to authenticate as a client device to a neighboring server (see
).
Note: It is worth noting that changes are being introduced to the way that dates are handled from 2050, and
certificates that have expiry dates beyond that can cause operational issues.
certificates that have expiry dates beyond that can cause operational issues.
Generating a Certificate Signing Request (CSR)
A CSR contains the identity information about the owner of a private key. It can be passed to a third-party or internal
certification authority for generating a signed certificate, or it can be used in conjunction with an application such as
Microsoft Certification Authority or OpenSSL.
certification authority for generating a signed certificate, or it can be used in conjunction with an application such as
Microsoft Certification Authority or OpenSSL.
Creating a CSR Using VCS
The VCS can generate server certificate signing requests. This removes the need to use an external mechanism to
generate and obtain certificate requests.
generate and obtain certificate requests.
7
Cisco VCS Certificate Creation and Use Deployment Guide
Generating a Certificate Signing Request (CSR)