Cisco TelePresence Video Communication Server Expressway User guide

Cisco Expressway Certificate Creation And Use Deployment Guide

(X12.5)

First Published: 2009-11-27

Last Modified: 2020-02-07

Americas Headquarters

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

http://www.cisco.com

Tel: 408 526-4000

800 553-NETS (6387)

Fax: 408 527-0883

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,

INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,

EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH

THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,

CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.

CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT

LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS

HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network

topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional

and coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com

go trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any

other company. (1721R)

CONTENTS

Preface 1

CHAPTER 1

Change History 1

Introduction 3

CHAPTER 2

Introduction 3

Information Not Covered in this Guide 3

PKI Introduction 4

Certificate Use on the Expressway Overview 4

Certificate Generation Overview 5

Points to be Aware 6

Generate a Certificate Signing Request (CSR) 7

CHAPTER 3

Generate a CSR 7

Create a CSR Using Expressway 7

Server Certificates and Clustered Systems 8

Server Certificate Requirements for Unified Communications 9

CHAPTER 4

Cisco Unified Communications Manager Certificates 9

IM and Presence Service Certificates 9

Expressway Certificates 10

Use ACME on Expressway-E 15

CHAPTER 5

Use ACME on Expressway-E 15

ACME Deployment Overview 15

How ACME Works 16

Common Configuration 17

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

iii

Lets encrypt verification process 17

Frequent expiry and low impact renewal 18

Automated renewal mode 18

More about the virtual Apache host 19

Deploy ACME Certificate Service 20

Prerequisites 20

Append Let's Encrypt Root CA Certificate to Expressway Trust Stores 20

Append Let's Encrypt Intermediate CA Certificate to Expressway Trust Stores 21

Configure ACME Certificate Service on Expressway-E 22

Configure ACME for Each Domain Certificate 22

Generate a Certificate Signing Request for ACME 23

Sign the CSR using ACME Provider 23

[Optional] Check the Signed ACME Certificate 23

Deploy the ACME Certificate 24

Enable Automated Renewal of the ACME Certificate 24

Revoke an ACME Certificate 25

View the Currently Uploaded Certificate 27

CHAPTER 6

View currently uploaded certificate 27

Load Certificates and Keys Onto Expressway 29

CHAPTER 7

Load Certificates and Keys Onto Expressway 29

Load a Server Certificate and Private Key Onto Expressway 30

Manage the Trusted CA Certificate List 31

Manage Certificate Revocation Lists (CRLs) 33

CHAPTER 8

Manage Certificate Revocation Lists 33

Certificate Revocation Sources 33

Limitations and Usage Guidelines 33

Automatic CRL Updates 34

Manual CRL Updates 35

Online Certificate Status Protocol (OCSP) 35

Configure Revocation Checking for SIP TLS Connections 35

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

iv

Contents

Troubleshooting 37

APPENDIX A

SIP TLS Negotiation Failures on Neighbor and Traversal Zones 37

Certificates with Key Length of 8192 Bits 37

Service Failures when Using Mobile and Remote Access 37

Issues with SSH Failures and Unsupported OIDs 37

Generate Certificate Using OpenSSL Only 39

APPENDIX B

Certificate Generation Using OpenSSL Only 39

Create a Certificate Request Using OpenSSL 40

Operate as a Certificate Authority Using OpenSSL 42

Configure OpenSSL Act as CA 42

Create Certificate Authority Using OpenSSL 42

Create Signed Certificate Using OpenSSL 44

Create Self-Signed Certificates Using OpenSSL 44

Convert a DER Certificate File to PEM Format 45

APPENDIX C

Convert a DER Certificate File to PEM Format 45

Decode Certificates 49

APPENDIX D

Decode Certificates 49

Enable AD CS to Issue "Client and Server" Certificates 51

APPENDIX E

Enable AD CS to Issue "Client and Server" Certificates 51

Authorize a Request and Generate a Certificate Using Microsoft Certification Authority 57

APPENDIX F

Authorize a Request and Generate Certificate using Microsoft Certificate Authority 57

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

v

Contents

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

vi

Contents

CHAPTER 1

Preface

•Change History, on page 1

Change History

Table 1: Certificate Creation and Use Deployment Guide Change History

ReasonChangeDate

Document correctionUpdated the "Create a CSR using Expressway" section

regarding multi-SAN certificate.

February

2020

Document correctionUpdated prerequisites for deploying ACME certificate service.December

2019

X12.5.2 releaseUpdates for maintenance release X12.5.2.April 2019

X12.5 releaseUpdated for X12.5 for ACME certificate management. Other

minor corrections.

January 2019

X8.11.1 releaseUpdated software version from X8.11 to X8.11.1, as version

X8.11 is no longer available.

September

2018

X8.11 release (withdrawn)Updated for X8.11.July 2018

Fixed in X8.10Remove 999 character SAN limitation.September

2017

X8.10 releaseDescription of new warning messages for server certificate

upload added. Changed UI menu path. Combined VCS and

Expressway versions of document.

July 2017

X8.9 releaseClarified requirements for MRA certificates.December

2016

X8.8 releaseUpdated for X8.8.June 2016

New template applied. Republished for X8.7.November

2015

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

1

ReasonChangeDate

Updated for X8.6.July 2015

Update for X8.5.2. Changes to CRL information, CSR

generation page defaults, 999 character limit on SANs.

April 2015

Update for X8.5.1. Introduced an option on the user interface

to select the Digest algorithm . The default is set to SHA-256

(hash algorithm).

January 2015

Re-issued for X8.5. Notes inserted over 2050 date

management, and unsupported OIDs. Changed instructions

in Appendix 2 "Creating a certificate request using OpenSSL".

December

2014

Re-issued for X8.2. Recommended options changed for server

certificate in Unified Communications deployments.

July 2014

Republished for X8.2. Enhanced the server certificate

requirements for Unified Communications deployments.

June 2014

Initial release of Expressway version.

(Compared to previous, VCS-only version) Updated for X8.1.

Removed "Certificate generation using Microsoft OCS"

appendix. Various improvements and clarifications to

"Certificate generation using OpenSSL only" appendix.

December

2013

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

2

Preface

Change History

CHAPTER 2

Introduction

•Introduction, on page 3

•Information Not Covered in this Guide, on page 3

•PKI Introduction, on page 4

•Certificate Use on the Expressway Overview, on page 4

•Certificate Generation Overview, on page 5

•Points to be Aware, on page 6

Introduction

New features in software version X12.5 and later are not supported for the Cisco TelePresence Video

Communication Server (VCS) product. They apply only to the Cisco Expressway Series (Expressway) product.

This software version is provided to VCS for maintenance and bug fixing purposes only.

Important

From version X12.5 onwards, this guide applies only to the Cisco Expressway Series (Expressway) product

and no longer applies to the Cisco TelePresence Video Communication Server (VCS) product. Older VCS

guides on Cisco.com are still valid for the VCS versions they apply to—as specified on the title page of each

guide.

This deployment guide provides instructions on how to create X.509 cryptographic certificates for use with

the Cisco Expressway (Expressway), and how to load them into Expressway.

Information Not Covered in this Guide

This document does not cover the following Expressway configuration topics, which are instead covered in

the Administrator Guide, or the appropriate HCS douments:

• Certificate-based authentication

• TLS version and cipher suites

• Domain certificates and Server Name Indication (SNI) for multitenancy (HCS)

• Domain certificates in clustered systems (HCS)

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

3

• Using ACME to manage domain certificates (HCS)

PKI Introduction

Public Key Infrastructure (PKI) provides the mechanisms through which you can secure communications

(encrypted and integrity protected) and verify the identities. Underlying PKI is:

•A public/private key pair: a public key is used to encrypt data that is sent to a server, but only the

private key (kept secret by the server) can be used to decrypt it.

•Signatures of data: server “signs” data using a combination of a cryptographic hash of the data and the

server’s private key. A client can verify the signature using server’s public key and the same hash. This

ensures that the data is sent from the expected server, and is not tampered with.

•Certificates: a certificate is a wrapper around a public key, and provides information about the owner

of the key in X.509 format, and typically includes server name and contact details.

•A certificate chain: Certificate Authority (CA) signs a certificate using its own private key. In turn, you

can verify a certificate as signed by checking the signature against the CA’s certificate (public key). Web

browsers and other clients have a list of CA certificates that they trust, and can thus verify the certificates

of individual servers.

Transport Layer Security (TLS) is the standard mechanism for securing a TCP connection between hosts on

a TCP/IP network. For example, secure HTTP (HTTPS) uses TLS to encrypt and verify traffic. To establish

a TLS connection:

1. The client sends its capabilities (including cipher suites) and a random number to make an initial TCP

connection.

2. The server responds with its choice of those capabilities, another random number, and its certificate.

3. The client verifies that the server certificate is issued (signed) by a CA that it trusts, and it is not revoked.

4. The client sends a “pre-master secret”, encrypted with the server’s public key.

5. This pre-master secret, combined with the exchanged random numbers (to prevent replay attacks), is used

to generate a “master secret”. This master secret keeps the remaining communications of this TLS session

encrypted between the client and server.

The following sections describe how these PKI components can be used with the Expressway.

Certificate Use on the Expressway Overview

Expressway needs certificates for:

• Secure HTTP with TLS (HTTPS) connectivity

• TLS connectivity for SIP signaling, endpoints and neighbor zones

• Connections to other systems such as Unified CM, Cisco TMS, LDAP servers and syslog servers

It uses its list of trusted Certificate Authority (CA) certificates and associated certificate revocation lists (CRLs)

to validate other devices connecting to it.

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

4

Introduction

PKI Introduction

The Expressway 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.

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*

You manage the Cisco Expressway's server certificate through the Server certificate page (Maintenance >

Security >Server certificate). This certificate is used to identify the Expressway when it communicates with

client systems using TLS encryption, and with web browsers over HTTPS. You can use the Server certificate

page to:

• View details about the currently loaded certificate.

• Generate a certificate signing request.

• Upload a new server certificate.

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.

The Expressway also supports the Automated Certificate Management Environment (ACME), and you can

configure it to automatically request and deploy certificates signed by the Let's Encrypt®certificate authority.

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:

•Generate a CSR, describes how to use the Expressway itself to generate the private key and certificate

request.

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

5

Introduction

Certificate Generation Overview

•Certificate Generation Using OpenSSL Only, documents the OpenSSL-only process, 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 Enable AD CS to Issue "Client and Server" Certificates).

Points to be Aware

• Some deployments rely on SANs (Subject Alternate Names) to implement TLS connections to

other Cisco or third-party infrastructure. You need to check the documentation for your

deployment before you order the certificate.

• When you generate a CSR using external systems, ensure that the CSR does not contain any

unsupported OIDs. Currently, only the following Extended Validation OIDs are supported.

• 1.3.6.1.4.1.311.60.2.1.1 jurisdictionOfIncorporationLocalityName

• 1.3.6.1.4.1.311.60.2.1.2 jurisdictionOfIncorporationStateOrProvinceName

• 1.3.6.1.4.1.311.60.2.1.3 jurisdictionOfIncorporationCountryName

For more information on how to verify if there are unsupported OIDs in the certificate, see the

section Issues with SSH Failures and Unsupported OIDs.

.

• Wildcard certificates manage multiple subdomains and the services names they support. They

can be less secure than SAN certificates and are not supported by Expressway.

• 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.

•The Expressway mechanism for CA certificate checking, requires the BasicConstraints extension

to be present.

• We highly recommend using certificates based on RSA keys. Other types of certificate, such

as those based on DSA keys, are not tested and may not work with the Expressway in all

scenarios.

• Do not allow your server certificate to expire as this may cause other external systems to reject

your certificate and prevent the Expressway from being able to connect to those systems.

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

6

Introduction

Points to be Aware

CHAPTER 3

Generate a Certificate Signing Request (CSR)

•Generate a CSR, on page 7

•Create a CSR Using Expressway, on page 7

Generate a 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 ACME, Microsoft Certification Authority, or OpenSSL.

Create a CSR Using Expressway

The Expressway can generate server certificate signing requests. This removes the need to use an external

mechanism to generate and obtain certificate requests.

To generate a CSR:

Procedure

Step 1 Go to Maintenance > Security > Server certificate.

Step 2 Click Generate CSR to go to the Generate CSR page.

Step 3 Enter the required properties for the certificate:

a. See Server Certificates and Clustered Systems, if your Expressway is part of a cluster.

b. See Server Certificate Requirements for Unified Communications, on page 9, if this Expressway is part

of a Unified Communications solution.

c. The certificate request includes, automatically, the public key that is used in the certificate and, the client

and server authentication Enhanced Key Usage (EKU) extension.

Step 4 Click Generate CSR. The system produces a signing request and an associated private key. The private key

is stored securely on the Expressway and cannot be viewed or downloaded. You must never disclose your

private key, not even to the certificate authority.

Step 5 You are returned to the Server certificate page. From here you can:

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

7

a. Download the request to your local file system so that it can be sent to a certificate authority. You are

prompted to save the file (the exact wording depends on your browser).

b. View the current request (click Show (decoded) to view it in a human-readable form, or click Show

(PEM file) to view the file in its raw format).

c. Use ACME to manually or automatically submit the CSR to a CA that signs ACME certificates.

•Only one signing request can be in progress at any point of time. This is because the Expressway

has to keep track of the private key file associated with the current request. To discard the

current request and start a new request, click Discard CSR.

• From version X8.5.1 the user interface provides an option to set the Digest algorithm. The

default is set to SHA-256, with options to change to SHA-1, SHA-384, or SHA-512.

• From version X8.10, you cannot select SHA-1.

• The Issuer and Subject fields of certificates returned by Let's Encrypt do not include attributes

like State, Country, and Organisation. The Expressway UI still requires you to complete these

fields in the CSR, even though the authority ignores them.

Note

You must now use CSR to generate a signed PEM certificate file. You can pass it to a third-party or internal

certification authority, or use it in conjunction with an application such as Microsoft Certification Authority

(see Authorize a Request and Generate Certificate using Microsoft Certificate Authority) or OpenSSL (see

Operate as a Certificate Authority Using OpenSSL).

If you have multiple entries or FQDNs in the SAN (such as for MRA deployments), ensure that you ask for

a multi-domain / multi-SAN certificate from your certificate authority, not a single certificate. Some authorities

do not suggest this option unless you specifically request it.

When the signed server certificate is received back from the certificate authority, upload it to the Expressway

as described in Load Certificates and Keys Onto Expressway.

Server Certificates and Clustered Systems

When a CSR is generated, a single request and private key combination is generated for that peer only.

If you have a cluster of Expressways, you must generate a separate signing request on each peer. Those

requests must then be sent to the certificate authority and the returned server certificates uploaded to each

relevant peer.

You must ensure that the correct server certificate is uploaded to the appropriate peer, otherwise the stored

private key on each peer will not correspond to the uploaded certificate.

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

8

Generate a Certificate Signing Request (CSR)

Server Certificates and Clustered Systems

CHAPTER 4

Server Certificate Requirements for Unified

Communications

•Cisco Unified Communications Manager Certificates, on page 9

•IM and Presence Service Certificates, on page 9

•Expressway Certificates, on page 10

Cisco Unified Communications Manager Certificates

Two Cisco Unified Communications Manager certificates are significant for Mobile and Remote Access:

•CallManager certificate

•tomcat certificate

These certificates are automatically installed on the Cisco Unified Communications Manager and by default

they are self-signed and have the same common name (CN).

We recommend using CA-signed certificates. However, if you do use self-signed certificates, the two certificates

must have different common names. The Expressway does not allow two self-signed certificates with the

same CN. So if the CallManager and tomcat self-signed certificates have the same CN in the Expressway's

trusted CA list, the Expressway can only trust one of them. This means that either secure HTTP or secure

SIP, between Expressway-C and Cisco Unified Communications Manager, will fail.

Also, when generating tomcat certificate signing requests for any products in the Cisco Collaboration Systems

Release 10.5.2, you need to be aware of CSCus47235. You need to work around this issue to ensure that the

FQDNs of the nodes are in the certificates as Subject Alternative Name (SAN) entries. The Expressway X8.5.3

Release Note on the Release Notes page has details of the workarounds.

IM and Presence Service Certificates

Two IM and Presence Service certificates are significant if you use XMPP:

•cup-xmpp certificate

•tomcat certificate

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

9

We recommend using CA-signed certificates. However, if you do use self-signed certificates, the two certificates

must have different common names. The Expressway does not allow two self-signed certificates with the

same CN. If the cup-xmpp and tomcat (self-signed) certificates have the same CN, Expressway only trusts

one of them, and some TLS attempts between Cisco Expressway-E and IM and Presence Service servers will

fail. For more details, see CSCve56019.

Expressway Certificates

The Expressway certificate signing request (CSR) tool prompts for and incorporates the relevant Subject

Alternative Name (SAN) entries as appropriate for the Unified Communications features that are supported

on that Expressway.

The following table shows which CSR alternative name elements apply to which Unified Communications

features:

When generating a CSR for these purposesAdd these items as

subject alternative

names

Business to Business

Calls

XMPP FederationJabber GuestMobile and Remote

Access

———Required on

Expressway-E only

Unified CM

registrations

domains (despite

their name, these

have more in

common with

service discovery

domains than with

Unified CM SIP

registration

domains)

—Required on

Expressway-E only

——XMPP federation

domains

—Required——IM and Presence

chat node aliases

(federated group

chat)

———Required on

Expressway-C only

Unified CM phone

security profile

names

—Required on

Expressway-C only

Required on

Expressway-C only

Required on

Expressway-C only

(Clustered systems

only) Expressway

Cluster name

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

10

Server Certificate Requirements for Unified Communications

Expressway Certificates

• You may need to produce a new server certificate for the Expressway-C if chat node aliases are added

or renamed. Or when IM and Presence nodes are added or renamed, or new TLS phone security profiles

are added.

• You must produce a new Expressway-E certificate if new chat node aliases are added to the system, or

if the Unified CM or XMPP federation domains are modified.

• You must restart the Expressway for any new uploaded server certificate to take effect.

More details about the individual feature requirements per Expressway-C / Expressway-E are described below.

Note

Expressway-C server certificate requirements

The Expressway-C server certificate must include the elements listed below in its list of subject alternative

names (SAN).

•Unified CM phone security profile names: the names of the Phone Security Profiles in Unified CM

that are configured for encrypted TLS and are used for devices requiring remote access. Use the FQDN

format and separate multiple entries with commas.

Having the secure phone profiles as alternative names means that Unified CM can communicate via TLS

with the Expressway-C when it is forwarding messages from devices that use those profiles.

•IM and Presence chat node aliases (federated group chat): the Chat Node Aliases (e.g.

chatroom1.example.com) that are configured on the IM and Presence servers. These are required only

for Unified Communications XMPP federation deployments that intend to support group chat over TLS

with federated contacts.

The Expressway-C automatically includes the chat node aliases in the CSR, providing it has discovered

a set of IM&P servers.

We recommend that you use DNS format for the chat node aliases when generating the CSR. You must include

the same chat node aliases in the Expressway-E server certificate's alternative names.

Figure 1: Enter subject alternative names for security profiles and chat node aliases on the Expressway-C's CSR generator

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

11

Server Certificate Requirements for Unified Communications

Expressway Certificates

Expressway-E server certificate requirements

The Expressway-E server certificate must include the elements listed below in its list of subject alternative

names (SAN). If the Expressway-E is also known by other FQDNs, all of the aliases must be included in the

server certificate SAN.

•Unified CM registrations domains: all of the domains which are configured on the Expressway-C for

Unified CM registrations. Required for secure communications between endpoint devices and

Expressway-E.

The Unified CM registration domains used in the Expressway configuration and Expressway-E certificate,

are used by Mobile and Remote Access clients to lookup the _collab-edge DNS SRV record during

service discovery. They enable MRA registrations on Unified CM, and are primarily for service discovery.

These service discovery domains may or may not match the SIP registration domains. It depends on the

deployment, and they do not have to match. One example is a deployment that uses a .local or similar

private domain with Unified CM on the internal network, and public domain names for the Expressway-E

FQDN and service discovery. In this case, you need to include the public domain names in the

Expressway-E certificate as SANs. There is no need to include the private domain names used on Unified

CM. You only need to list the edge domain as a SAN.

Select the DNS format and manually specify the required FQDNs. Separate the FQDNs by commas if

you need multiple domains. You may select CollabEdgeDNS format instead, which simply adds the

prefix collab-edge. to the domain that you enter. This format is recommended if you do not want to

include your top level domain as a SAN (see example in following screenshot).

•XMPP federation domains: the domains used for point-to-point XMPP federation. These are configured

on the IM&P servers and should also be configured on the Expressway-C as domains for XMPP federation.

Select the DNS format and manually specify the required FQDNs. Separate the FQDNs by commas if

you need multiple domains. Do not use the XMPPAddress format as it may not be supported by your

CA, and may be discontinued in future versions of the Expressway software.

•IM and Presence chat node aliases (federated group chat): the same set of Chat Node Aliases as

entered on the Expressway-C's certificate. They are only required for voice and presence deployments

which will support group chat over TLS with federated contacts.

You can copy the list of chat node aliases from the equivalent Generate CSR page on the Expressway-C.

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

12

Server Certificate Requirements for Unified Communications

Expressway Certificates

Figure 2: Enter subject alternative names for Unified CM registration domains, XMPP federation domains, and chat node aliases, on the

Expressway-E's CSR generator

See Cisco Expressway Certificate Creation and Use Deployment Guide on the Expressway configuration

guides page.

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

13

Server Certificate Requirements for Unified Communications

Expressway Certificates

Cisco Expressway Certificate Creation And Use Deployment Guide (X12.5)

14

Server Certificate Requirements for Unified Communications

Expressway Certificates

Page is loading ...

Cisco TelePresence Video Communication Server Expressway User guide

This manual is also suitable for

Cisco TelePresence Video Communication Server Expressway User guide

Related papers

Other documents