Security CertificatesAn Introduction

David Lover Vice President Strategy and Technology

2

Introduction to Security Certificates

> Why do you need to understand Digital

Certificates

> Introduction to PKI – Public Key

Infrastructure

– What is a Security Certificate?

– What is a Certificate Authority?

> Avaya’s use of Security Certificates

> High-level deployment tasks

> Specific example of deploying certificates

3

Need for Understanding Digital Certificates

> X509 Digital Certificates represent the identity and privacy “keys” in TLS based

communication

– SSL 2.0 -> SSL 3.0 ->TLS 1.0 -> TLS 1.1-> TLS 1.2 ->TLS 1.3 (Draft)

> Avaya has been allowing customers to use their “Demo” Security Certs.

> They began phasing that out in Aura R6 due to the older cipher strength (1024 bits

versus 2048 bits) and lack of “uniqueness”.

> Demo” certs are no longer installed by default (but are kept during an upgrade)

> Customers must adopt and maintain a certificate strategy for their Aura system

4

Sample TLS Message Flow

5

TLS Security Certificates – Identity Certificate

> A Security Certificate provides a mechanism to provide identity and encryption

> A Security Certificate must be signed by a “trusted” Certificate Authority

> X509 allows for various scopes of “Trust” through the use of Root Certificate

Authority (CA) certs– Commercial (sometimes called 3rd Party Certs)

– Enterprise

6

Certificate Authority (often referred to as the CA)

> Verifies the identity. The CA must validate the identity of the entity who requested a

digital certificate.

> Issues digital certificates. If the validation process succeeds, the CA issues the digital

certificate to the entity that requested it.

> Maintains the Certificate Revocation List (CRL). A CRL is a list of digital certificates

that are no longer valid and have been revoked. These digital certificates are not

reliable.

7

Signing a Security Certificate

> Avaya Elements that depend on System Manager for their trust management (ie

Session Manager) this is done via System Manager

> If Element supports CSR, use the tools provided in that element to create a CSR,

transfer the file to the Certificate Authority for signing, install the signed certificate

on the element (PEM or PKCS#12)

> If the Element doesn’t support CSR, then create a cert directly within the

Certificate Authority. This signed cert will be in a PKCS#12 format, containing the

Private Key to be used by the element.

8

Certificate Authorities

9

Migration Strategy

> Identify overall Certificate Authority strategy (Public CA, Enterprise CA, SMGR

CA, Hybrid)

> Inventory infrastructure to determine which Certs need to be upgraded and who

will need a copy of its Root CA Certificates

> Create new Identity Certs (via CSR, when available).

> Obtain and Deploy the Root CA’s associated with the new Identity Certs

> Install new Identity Certs and Test Functionality

> Remove old Root CA’s

10

Migration Strategy

> Identify overall Certificate Authority strategy (Public CA, Enterprise CA,

SMGR CA, Hybrid)

> Inventory infrastructure to determine which Certs need to be upgraded and who

will need a copy of its Root CA Certificates

> Obtain and Deploy the Root CA’s associated with the new Identity Certs

> Install new Identity Certs and Test Functionality

> Remove old Root CA’s

11

TLS Security Certificate Strategies

> Continue using weak “Demo” certs

> Use your existing Enterprise Root Certificate Authority

> Use System Manager as the Enterprise Root Certificate Authority

> Use System Manager as an Intermediate CA of your Enterprise Root Certificate

Authority

> Use Commercial Root CA’s (Thawte, Verisign, etc)

> Use a combination of the above strategies

12

TLS Security CertificatesContinue using Avaya “Demo” certs

> Advantages– Easiest option. Most Avaya products still support it.

Some are “hard coded” to trust it.

– Extended expiration date

> Disadvantages– Non-unique

– Weak Cipher strength

– Do not meet current NIST standards

– Avaya will NOT be renewing these certs. Once they

expire, they are dead forever.

13

TLS Security CertificatesUse your Existing Enterprise CA

> Advantages– Root CA certs tend to already be deployed to enterprise

clients and pc’s

– Can have a longer expiration

– Lets your enterprise manage acquisition of certs for you

> Disadvantages– By default, no one outside of your enterprise will trust these

certs

– Lose the benefit of “automatic” cert acquisition from

“enrolling” with System Manager

– Requires coordination with your Enterprise Certificate team

14

TLS Security CertificatesUse System Manager as the Enterprise Root CA

> Advantages– Allows easier acquisition of Root CA certs upon installation

by “enrolling” with System Manager

– Let’s you be independent of external departments

> Disadvantages– Root CA certs not deployed to enterprise users by default

– Root CA certs not deployed to public users by default

– Multiple Certificate Authority Servers to Manage and keep

track of

15

TLS Security CertificatesUse System Manager as an Intermediate CA

> Advantages– Allows easier acquisition of Root CA certs upon installation by

“enrolling” with System Manager

– Let’s you be independent of external departments

– Let’s existing Enterprise Root CA’s trust System Manager

signed certs

> Disadvantages– Root CA certs not deployed to enterprise users by default

– Need to get buy-in from existing Enterprise CA owners to

become a delegate

– Some devices expect to see the full trust chain

16

TLS Security CertificatesUse 3rd Party Commercial CA

> Advantages– Most devices and operating systems come preloaded

with the common, well known CA Root Certificates

> Disadvantages– Short Expirations (1-2 years typical)

– Can be expensive

– Lose the benefit of “automatic” cert acquisition from

“enrolling” with System Manager

– Not all CA’s support the requirements of certain Avaya

servers

17

Migration Strategy

> Identify overall Certificate Authority strategy (Public CA, Enterprise CA, SMGR

CA, Hybrid)

> Inventory infrastructure to determine which Certs need to be upgraded

and who will need a copy of its Root CA Certificates

> Obtain and Deploy the Root CA’s associated with the new Identity Certs

> Install new Identity Certs and Test Functionality

> Remove old Root CA’s

18

TLS Security Certificates – Inventory

19

TLS Security Certificates – Inventory

20

TLS Security Certificates – Inventory

21

Migration Strategy

> Identify overall Certificate Authority strategy (Public CA, Enterprise CA, SMGR

CA, Hybrid)

> Inventory infrastructure to determine which Certs need to be upgraded and who

will need a copy of its Root CA Certificates

> Obtain and Deploy the Root CA’s associated with the new Identity Certs

> Install new Identity Certs and Test Functionality

> Remove old Root CA’s

22

Migration Strategy

> Identify overall Certificate Authority strategy (Public CA, Enterprise CA, SMGR

CA, Hybrid)

> Inventory infrastructure to determine which Certs need to be upgraded and who

will need a copy of its Root CA Certificates

> Obtain and Deploy the Root CA’s associated with the new Identity Certs

> Install new Identity Certs and Test Functionality

> Remove old Root CA’s

23

Obtain New Root CA Cert

24

Obtain New Root CA Cert

25

Deploy New Root CA Cert – Communication Manager

26

Deploy New Root CA Cert – Communication Manager

27

Deploy New Root CA Cert – Communication Manager

Communication Manager

requires a restart for it to use

the new Root CA Trust Cert

28

Deployment of New Root CA Cert

> Avaya hard phones get their TLS settings

from the 46xxsettings.txt file

> Keep the existing CA for now. You should

remove it once you’ve tested with new

Identity Cert

> Phones must be rebooted to re-process

the 46xxsettings.txt file

29

Migration Strategy

> Identify overall Certificate Authority strategy (Public CA, Enterprise CA, SMGR CA,

Hybrid)

> Inventory infrastructure to determine which Certs need to be upgraded and who will

need a copy of its Root CA Certificates

> Create new Identity Certs (via CSR, when available).

> Obtain and Deploy the Root CA’s associated with the new Identity Certs

> Install new Identity Certs and Test Functionality

> Remove old Root CA’s

30

Replace Identity Certs

31

Replace Identity Certs – Security Module SIP

32

Replace Identity Certs - Security Module SIP

33

Replace Identity Certs - HTTPS

34

Check the Compliance Status

35

Migration Strategy

> Identify overall Certificate Authority strategy (Public CA, Enterprise CA, SMGR CA,

Hybrid)

> Inventory infrastructure to determine which Certs need to be upgraded and who will

need a copy of its Root CA Certificates

> Create new Identity Certs (via CSR, when available).

> Obtain and Deploy the Root CA’s associated with the new Identity Certs

> Install new Identity Certs and Test Functionality

> Remove old Root CA’s

36

Migration Strategy - Remove Old Root CA’s

> Be VERY careful when doing

this. Make sure there are no

remaining identity certs signed

by the old CA.

> CM must be restarted

37

Migration Strategy - Remove Old Root CA’s

> Be VERY careful when doing

this. Make sure there are no

remaining identity certs

signed by the old CA.

> Phones must be rebooted

38

Introduction to Security Certificates

> Why do you need to understand

Digital Certificates

> Introduction to PKI – Public Key

Infrastructure

– What is a Security Certificate?

– What is a Certificate Authority?

> Avaya’s use of Security Certificates

> High-level deployment tasks

> Specific example of deploying

certificates

39

Join Us For Our October Webinar!

Join us on October 20th at 10am CST

Join Andrew Prokop as he explains the fundamentals of Avaya Breeze before

walking you through the creation of a few Breeze applications.

Registration Link: http://go.arrowsi.com/instantinsightoctober2016register

Security CertificatesAn Introduction

David Lover Vice President Strategy and Technology