Cisco Cisco 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
Expressway is the device it says it is. This can be used with neighboring devices such as Microsoft Lync or
Unified CM, as well as administrators using the web interface.
Expressway is the device it says it is. This can be used with neighboring devices such as Microsoft Lync or
Unified CM, as well as administrators using the web interface.
A certificate identifies the Expressway. It contains names by which it is known and to which traffic is routed.
If the Expressway 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 Expressway 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 Expressway 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 Expressway 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 Expressway is not clustered:
n
Subject Common Name = FQDN of Expressway
n
Subject Alternate Names = leave blank
If the Expressway is clustered, with individual certificates per Expressway:
n
Subject Common Name = FQDN of Expressway
n
Subject Alternate Names = FQDN of Expressway, 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. Expressway does not support wildcard certificates.
secure than SAN (Subject Alternate Name) certificates. Expressway 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 Expressway 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 Expressway 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
Expressway, and private key:
Expressway, and private key:
n
generate the private key and certificate request.
n
which could be used with a third party or internally managed CA.
For mutual TLS authentication the Expressway Server certificate must be capable of being used as a Client
certificate as well, thus allowing the Expressway to authenticate as a client device to a neighboring server
(see
certificate as well, thus allowing the Expressway to authenticate as a client device to a neighboring server
(see
).
Cisco Expressway Certificate Creation and Use Deployment Guide (X8.2)
Page 4 of 29
Introduction