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. 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:
■ Subject Common Name = FQDN of Expressway
■ Subject Alternate Names = leave blank*
If the Expressway is clustered, with individual certificates per Expressway:
■ Subject Common Name = FQDN of cluster
■ Subject Alternate Name = FQDN of Expressway peer, FQDN of cluster*
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.
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
Expressway, and private key:
■ Generating a Certificate Signing Request (CSR), page 6 describes how to use the Expressway itself to
generate the private key and certificate request.
■ Appendix 2: Certificate Generation Using OpenSSL Only, page 19 documents the OpenSSL-only process,
which could be used with a third party or internally managed CA.
For mutual TLS authentication the ExpresswayServer 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
Appendix 5: Enable ADCSto Issue "Client and Server" Certificates, page 31).
Important:
■ * Some deployments rely on SANs to implement TLS connections to other Cisco or third-party infrastructure.
Read the documentation for your deployment before ordering your certificate.
■ 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.
■ 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.
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.
6
Cisco Expressway Certificate Creation and Use Deployment Guide
Generating a Certificate Signing Request (CSR)