Cisco Expressway Series User guide

Cisco Expressway Certificate Creation and Use Deployment Guide

(X14.0)

First Published: 2021-02-23

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:

https://www.cisco.com/c/en/us/about/legal/trademarks.html. 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

Generating a Certificate Signing Request 7

CHAPTER 3

Generating a CSR 7

Creating 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

Using ACME on Expressway-E 15

CHAPTER 5

Using ACME on Expressway-E 15

ACME Deployment Overview 15

How ACME Works 16

Common Configuration 17

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

iii

Lets encrypt verification process 18

Frequent expiry and low impact renewal 18

Automated renewal mode 19

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 21

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 23

Enable Automated Renewal of the ACME Certificate 24

Revoke an ACME Certificate 24

View the Currently Uploaded Certificate 27

CHAPTER 6

View currently uploaded certificate 27

Loading Certificates and Keys Onto Expressway 29

CHAPTER 7

Loading Certificates and Keys Onto Expressway 29

Managing the Trusted CA Certificate List 30

Loading a Server Certificate and Private Key Onto Expressway 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 (X14.0)

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 43

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 (X14.0)

v

Contents

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

vi

Contents

CHAPTER 1

Preface

•Change History, on page 1

Change History

Table 1: Certificate Creation and Use Deployment Guide Change History

ReasonChangeDate

Document correctionRemoved biased language from the "PKI Introduction"

section.

June 2020

X12.6Updated for X12.6June 2020

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

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

1

ReasonChangeDate

X8.8 releaseUpdated for X8.8.June 2016

New template applied. Republished for X8.7.November

2015

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 (X14.0)

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 Expressway Administrator Guide:

• How to enable certificate-based authentication on Expressway

• Details of root CAs pre-installed in Expressway

• How to configure minimum TLS versions and cipher suites

• How to test client certificates

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

3

• Managing mTLS certificates (Mobile and Remote Access deployments)

• Domain certificates and Server Name Indication for multitenancy (Hosted Collaboration Solution

deployments)

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 secret”, encrypted with the server’s public key.

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

generate a “shared secret”. This shared 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

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

4

Introduction

PKI Introduction

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

to validate other devices connecting to it.

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:

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

5

Introduction

Certificate Generation Overview

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

request.

•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 (X14.0)

6

Introduction

Points to be Aware

CHAPTER 3

Generating a Certificate Signing Request

•Generating a CSR, on page 7

•Creating a CSR Using Expressway, on page 7

Generating a CSR

A Certificate Signing Request (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.

Creating 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:

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 the "Server Certificates Requirements for Unified Communications" section, 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:

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

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

7

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 Loading 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 (X14.0)

8

Generating a Certificate Signing Request

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 (X14.0)

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 (X14.0)

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

are configured for encrypted Transport Line Signaling (TLS) and are used for devices requiring remote

access. Use the Fully Qualified Domain Name (FQDN) format and separate multiple entries with commas.

It is essential to generate Certificate Signing Request (CSR) for the new node while adding a new

Expressway-C node to an existing cluster of Expressway-C. It is mandated to put secure profile names

as they are on CUCM, if secure registration of Mobile and Remote Access (MRA) client is needed over

MRA. CSR creation on the new node will fail if “Unified CM phone security profile names” are just

names or hostnames on CUCM device security profiles. This will force Administrators to change the

value of “Unified CM phone security profile names” on CUCM under the Secure Phone Profile page.

From X12.6, it is mandated that the Unified CM phone security profile name must be a Fully Qualified

Domain Name (FQDN). It cannot be just any name or hostname or a value.

For example, jabbersecureprofile.domain.com,DX80SecureProfile.domain.com

The FQDN can comprise multiple levels. Each level's name can only contain

letters, digits and hyphens, with each level separated by a period (dot). A level

name cannot start or end with a hyphen, and the final level name must start with

a letter.

Note

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

Transport Line Signaling (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.

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

11

Server Certificate Requirements for Unified Communications

Expressway Certificates

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

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.

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

12

Server Certificate Requirements for Unified Communications

Expressway Certificates

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

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

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

13

Server Certificate Requirements for Unified Communications

Expressway Certificates

Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)

14

Server Certificate Requirements for Unified Communications

Expressway Certificates

Page is loading ...

Cisco Expressway Series User guide

Cisco Expressway Series User guide

Related papers

Other documents