Avaya is putting the responsibility of choosing, obtaining, installing and renewing expiring certifications on you. Are you prepared for that? David is here to talk you through the basics in understanding and deploying these critical certifications.

1. Security Certificates
An Introduction
David Lover Vice President Strategy and Technology

2. 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. 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. 4
Sample TLS Message Flow

5. 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. 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. 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. 8
Certificate Authorities

9. 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. 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. 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. 12
TLS Security Certificates
Continue 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. 13
TLS Security Certificates
Use 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. 14
TLS Security Certificates
Use 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. 15
TLS Security Certificates
Use 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. 16
TLS Security Certificates
Use 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. 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. 18
TLS Security Certificates – Inventory

19. 19
TLS Security Certificates – Inventory

20. 20
TLS Security Certificates – Inventory

21. 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. 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. 23
Obtain New Root CA Cert

24. 24
Obtain New Root CA Cert

25. 25
Deploy New Root CA Cert – Communication Manager

26. 26
Deploy New Root CA Cert – Communication Manager

27. 27
Deploy New Root CA Cert – Communication Manager
Communication Manager
requires a restart for it to use
the new Root CA Trust Cert

28. 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. 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. 30
Replace Identity Certs

31. 31
Replace Identity Certs – Security Module SIP

32. 32
Replace Identity Certs - Security Module SIP

33. 33
Replace Identity Certs - HTTPS

34. 34
Check the Compliance Status

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

40. Security Certificates
An Introduction
David Lover Vice President Strategy and Technology