Download - SHA-2 SHA-512/224, SHA-512/256. - RMAUGrmaug.org/Presentations/16MayPresentations/16-05-11AvayaCertificateMgmt.pdf · Default Certificates 1. Default certificates, also known as demo

Transcript

1

1. This talk provides guidance for migrating Avaya provided demonstration grade certificates to customer self-signed or trusted root 3rd party digital certificates. 2. The new generation of Avaya products will require servers to have certificates issued by a trusted Certificate Authority (CA) in order for the product to establish a secure connection.3. Administrators must review their networks to determine the certificates in use + decide whether to use CA certs to products including end-user devices, to replace server

certificates, or both. 4. Why is this happening - as with other forms of identification, certificate technology has progressed over the years. 5. Current standards mandate using newer algorithms than are in place in the default certificates that Avaya has shipped with Avaya Aura systems for demonstration, lab,

and isolated private network use, so use of these default certificates has now been deprecated and trust of the Avaya SIP Product CA has been removed from new products.

6. Avaya's recommendation is that customers upgrade their servers to use certificates generated to the current US National Institute of Standards and Technology (NIST) standards for information systems security. Detailed information for doing this upgrade is available in the product documentation.

7. The default certificates shipped with Avaya Aura Session Manager were intended for lab and demonstration use only. 8. Up to now, products have included support for these default certificates to facilitate lab testing. 9. Removing support for these default certificates from the products allows a customer with higher security needs to implement a strategy using current best practices.10. Avaya Aura® 6.2.x Feature Pack 1st release to officially support SHA2/204 certificates.

SHA-1A 160-bit hash function which resembles the earlier MD5 algorithm. This was designed by the National Security Agency (NSA) to be part of the Digital Signature Algorithm. Cryptographic weaknesses were discovered in SHA-1, and the standard was no longer approved for most cryptographic uses after 2010. SHA-2

A family of two similar hash functions, with different block sizes, known as SHA-256 and SHA-512. They differ in the word size; SHA-256 uses 32-bit words where SHA-512 uses 64-bit words. SHA-2 includes significant changes from its predecessor, SHA-1.

The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.

1. Nevertheless careful inspection of the entire infrastructure is a mandatory preliminary task to evaluate if all communicating parties (clients and servers) support the SHA2 signing algorithm.

What services are affected?1. All communications between two parties (client-server and server-server) in the Avaya Aura environment are secured using Transport Layer Security (TLS, a newer

version of SSL that you may be familiar with). 2. In TLS, servers are configured with an identity certificate issued by a certificate authority. 3. When products connect to servers, the server presents its identity certificate for the client to validate. 4. The client checks whether the server identity certificate was issued by a certificate authority that the client trusts (among other items). If everything checks out, then the

client proceeds and a secure connection is established.

1. Enhanced security is the overall motivator for migrating from demo to third party signed certificates. 2. This is achieved by deploying certificates with shorter validity, enhanced key length, stronger signing algorithms and a trusted issuing authority. 3. A Digital Certificate serves as a guarantee that the parties to a transaction are who they claim to be. 4. The certificate consists of a long string of binary code issued by a certification authority (CA). 5. The CA authenticates the parties' identities and

1. creates a public key for message encryption, 2. and a private key for message decryption. 3. A Digital Certificate does not imply anything about the transaction itself.

6. A Digital Certificate contains a certificate number, dates during which the certificate is valid, the CA's name and digital signature. Digital Certificates have a limited lifetime, usually one year.

7. The replying party checks if the CA is set as a trusted one in the party´s trusted CA key store, the expiration data of the Digital Certificate along with the signature and much more.

8. A Digital Certificate contains a certificate number, dates during which the certificate is valid, the CA's name and digital signature. Digital Certificates have a limited lifetime, usually one year.

9. The replying party checks if the CA is set as a trusted one in the party´s trusted CA key store, the expiration date of the Digital Certificate along with the signature and much more.

10. Many components have multiple trust stores. It has to be ensured that the CA root certificate is installed in each of the required trust stores.

2

Default Certificates1. Default certificates, also known as demo certificates, are non-unique identity certificates

issued by the Avaya SIP Product Certificate Authority for demonstration and lab testing only. Default certificates are very insecure and do not meet current NIST standards.

2. Continue to use the Default Certificates in an isolated LAN environment until the Demo Certificate expires if:

• You do not yet deploy or manage X.509 Certificates within your data network.• Your VOIP solution is completely isolated from internal and external data networks.

3. This strategy is not approved for production networks that are not isolated and sufficiently protected from eavesdropping. The certificates will NOT be renewed. Eventually, a different strategy MUST be used.

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

1. All communications between the client and the servers in the Avaya Aura environment are secured using a technology called Transport Layer Security (TLS, a newer version of SSL that you may be familiar with). In TLS, servers are configured with an identity certificate issued by a certificate authority. When clients connect to servers, the server presents its identity certificate for the client to validate. The client checks whether the server identity certificate was issued by a certificate authority that the client trusts (among other items). If everything checks out, then the client proceeds and a secure connection is established.

2. The color coding of each element reflects the issuing certificate authority for certificates presented by that element (see the legend for details).

3. Elements which may have certificates from multiple authorities are shown using a gradient fill.

4. Customers who have deployed the Avaya Unified Communications solution over time may have a very complex set of certificates and may require the installation of up to four CA certificates on client devices as well as replacing the default certificate on the Avaya one-X Client Enablement Services server.

5. The Avaya Aura team is working to simplify this situation; new installations will use the Avaya Aura System Manager as a certificate authority where possible and eliminate use of the Avaya SIP Product certificate authority entirely.

6. How to simplify your network Installing certificates issued by your enterprise certificate infrastructure or by a well-known certificate vendor will simplify your network + reduce the amount of work required for your users to start using the new Avaya products.

7. If you use a well-known certificate vendor that is already trusted by the end-user client devices, there is no need to deploy certificates to those devices at all.

8. If you have an enterprise certificate infrastructure, you may need to make the CA certificate available to end users so that they can install it on their client device and provide instructions for them to do so.

28

29

30

FundamentalsCertificate Authority (CA)

1. A Certificate Authority (CA) is a trusted entity that issues Digital Certificates and public-private key pairs. A Certificate Authority (CA) verifies the identity of an individual or organization before issuing a digital certificate.

2. A Certificate Authority (CA) • can be an external (public) Certificate Authority (CA) like Verisign, Thawte or Comodo, or an internal (private)

Certificate Authority (CA) configured inside an enterprise network. • A Certificate Authority (CA) is a critical security service in a network and performs the following functions:

- Verifies the identity. The Certificate Authority (CA) must validate the identity of the entity who requested a digital certificate.- Issues digital certificates. If the validation process succeeds, the Certificate Authority (CA) issues the digital certificate to the entity who requested it.- Maintains the Certificate Revocation List (CRL). A certificate revocation list (CRL) is a list of digital certificates that are no longer valid and have been revoked. These digital certificates are not reliable.

Public Key Infrastructure (PKI)The Public Key Infrastructure (PKI) is a system that creates, manages, stores, distributes, and revokes Digital Certificates. A PKI provides a method to securely and privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.A PKI consists of a:1. - Certificate Authority (CA) that both issues and verifies the digital certificates.2. - Registration Authority that verifies the identity of users requesting information from the CA.3. - Secure location in which to store and index keys.4. - Certificate management system.5. - Certificate policy.

A PKI can contain multiple levels with the root CA at the top level, and intermediate or subordinate CAs at lower levels. One of the subordinate CAs is the issuing CA that the end user contacts for certificate requests. The root CA may be off-line once the intermediate or subordinate CAs are in place. The digital identity certificate issued to the end user is linked back to the root CA using a chain of trust.

The major functions of a PKI are:1. - Confidentiality: Encryption of data streams and messages protects the privacy of user transactions. The confidentiality

function prevents the unauthorized disclosure of information locally or across a network. By using a PKI, users can ensure that only an intended recipient can decrypt an encrypted message.

2. - Authentication: Authentication is the process of verifying the identity of a user. PKI provides a means for senders and recipients to validate each other's identities.

3. - Integrity: PKI guarantees message integrity. PKI has built-in methods to validate that all the outputs are equivalent to the inputs, and immediately detects any changes to the data.

4. - Non-Repudiation: PKI ensures that an author cannot refute a particular signed or encrypted message from the author once the message has been sent, assuming the private key is secured. Digital signatures link senders to messages. Only the sender of the message can sign messages with the sender’s private key. Therefore, all messages signed with the sender's private key originated with that specific individual.

PKI cryptographic algorithms use the public key of the receiver of an encrypted message to encrypt data and the related private key to decrypt the encrypted message.

31

32

Through the support of 802.1X and Link Layer Discovery Protocol, Avaya IP telephones and PCs connected to the telephone’s data port can be authenticated separately, receive different port profiles for QoS and security policies, and communicate over different VLANs. This is accomplished with security features on both the phones and on the Ethernet switches that help guarantee standards-based, enterprise-class secure network access control. In addition, Avaya's support for LLDP provides the ability to consolidate information such as device-type, software version and serial number for inventory management. This same capability also provides a structured workflow for problem diagnosis and root-cause analysis in case of user-reported communication issues. When an IT administrator sees discovery protocol packets, they indicate that the phone is operational, the cable is intact and Layer 2 traffic is functioning. Together these features provide for a complete, interoperable, secure, and simple to deploy solution.

802.1X is an IEEE standard for port-based Network Access Control. It provides authentication to devices attached to an Ethernet switch port, allowing access from that port if authentication succeeds, or preventing access from that port if authentication fails. 802.1X is supported on most Ethernet switches to authenticate attached devices equipped with Supplicant software. Upon detection of a new device (Supplicant), the port on the Ethernet switch (the Authenticator) will be set to the Unauthorized state. In this state, only 802.1X traffic will be allowed; other traffic, such as DHCP and HTTP, will be blocked at the data link layer. The Authenticator will send an EAP-Request/Identity message to the Supplicant, and the Supplicant will respond with an EAPResponse/Identity message that the Authenticator will forward to the Authentication Server. The Authentication Server then requests authentication credentials from the Supplicant; if it is successful, the Authentication Server instructs the Authenticator to set the port to the Authorized state and allow normal traffic. When the Supplicant logs off or disconnects from the port, the Authenticator will return the port to the Unauthorized state, once again blocking all non-EAP traffic. The 802.1X standard assumes that only a single device is connected to each 802.1X-enabled Ethernet switch port (this is sometimes called Single Supplicant operation). Otherwise, if one device is authenticated and the port is set to the Authorized state, other devices would be able to access the network without being authenticated. However, inexpensive Ethernet hubs and switches are readily available, so it is difficult to prevent multiple devices from being connected. Therefore, most 802.1X-capable switches either block any frame that does not have the same MAC-layer Source Address that was used in the authentication message exchange, or they forward such frames only to a specific VLAN. Some Ethernet switches also go beyond the standard and have the ability to independently authenticate multiple devices on the same port (this is sometimes called Multi Supplicant operation). However, MAC addresses can be spoofed, so none of these approaches is completely foolproof.

33

34

35

36

What SMGR certificate management private key infrastructure do I want to adopt? Five choices:1. SMGR Self-Signed CA (SMGR-CA) - default2. SMGR Using Enterprise PKI Intermediate CA3. SMGR Using 3rd-Party Intermediate CA4. No SMGR CA – Import CA and ID Certs Provided by Enterprise PKI5. No SMGR CA – Import CA and ID Certs Provided by 3rd-Party PKI

1. What NIST compliant certificates will I use for non-Avaya elements?2. What NIST compliant certificates will I use for Avaya elements that are not wired into the SMGR PKI

(e.g. CM)? 3. What is my stepwise plan for the “Replace, Upgrade and/or Decommission” stage of the Migration

Activity? Do I break it up or do it all in one maintenance window? What is my safe rollback contingency

4. What is my stepwise plan for the “Trust Deployment with Auditing” stage of the Migration Activity? Do I break it up or do it all in one maintenance window? What is my safe rollback contingency?

5. What is my stepwise plan for the “Cleanup” stage of the Migration Activity? Do I break it up or do it all in one maintenance window? What is my safe rollback contingency?

6. How do I obtain the final root trust certificate for the scheme chosen in 1) a) above? It will be deployed to the trust store of all entities and endpoints that communicate with Session Manager. This will occur in the “Trust Deployment with Auditing” stage of the Migration Activity.

7. For each entity that will accept TLS connections from Session Manager or will mutually authenticate with Session Manager, how do I obtain its final root CA certificate? These certificates as a group will be deployed to Session Manager’s trust store in the “Trust Deployment with Auditing” stage of the Migration Activity.

8. Before I start the “Identity Deployment with Auditing” stage of the Migration Activity, how will I know that when I deploy the SMGR identity cert to its management interface that the managed elements will trust it?

9. Before I start the “Identity Deployment with Auditing” stage of the Migration Activity, How will I know that when I deploy the SM identity cert that the SM peer elements and endpoints will trust it?

10. Before I start the “Identity Deployment with Auditing” stage of the migration Activity, for each peer entity to SM that will be receiving a new identity cert, how will I know that when I deploy this element’s new identity cert that the SM will trust it?

37

1. In general, a hierarchy contains multiple CAs with clearly defined parent-child relationships. The CA at the top of a hierarchy is the root authority, or root CA.

2. Each CA hierarchy begins with the Root CA, + multiple CAs branch from the Root CA in a parent-child relationship.

3. Child CAs of the root CAs are called subordinate/intermediate certification authorities. See figure.

4. In this model, the child subordinate certification authorities are certified by their parent CA-issued certificates.

5. These certificates bind a certification authority's public key to its identity. 6. A PKI can contain multiple levels with the root CA at the top level, and intermediate or

subordinate CAs at lower levels. 7. One of the subordinate CAs is the issuing CA that the end user contacts for certificate

requests. 8. The root CA may be off-line once the intermediate or subordinate CAs are in place. The

Root CA is kept in a secure area and is usually a stand-alone offline CA. 9. The digital identity certificate issued to the end user is linked back to the root CA using a

chain of trust.10. All children CAs must be certified by the corresponding parent CA back to the Root CA. The

root CA provides certificates for intermediate CAs. The certificates can be revoked if they are compromised.

11. An Intermediate CA is subordinate to another CA, either a Root CA or another intermediate CA, and issues certificates to other CAs in the CA hierarchy.

12. Intermediate CAs are usually stand-alone offline CAs similar to Root CAs.13. Issuing CAs provide certificates to users, computers, and other services. 14. There can be multiple issuing CAs. For example, one issuing CA can generate computer

certificates and another can generate user certificates.

38

There are three basic concepts available for the Avaya UC environment:1. Use a customer owned PKI (Public Key Infrastructure) as the Certificate Authority (CA)2. Use a CA or a subordinate CA based on Avaya Aura System Manager (SMGR)3. Use a public or ´Well-known´ CA

No SMGR CA – Import CA and ID certs provided by 3rd-Party PKI The Public PKI vendor issues and revokes certificates and approves all renewals. There is no need to manage Trust Stores of Remote clients. Pros: Provides third party assured trust of enterprise i-CA.Cons: Very expensive and gets churns certs if managed elements change in a way that affects cert content.

Currently: Requires manual PKI trust chain distribution to Aura managed elements.Currently: Requires administrator handling of PKCS12 passphrase and therefore grants access to the unencrypted private key. NOTE: In some cases, CSR’s can be generated on Aura managed elements and manually exported for signing. A similar manual procedure is required to import the signed ID cert.Cannot automatically reissue certs as they near expiration.Deployment to Aura managed elements is manual and more error prone.Meeting NIST requirements is the enterprise’s responsibilityFuture : Meeting Avaya cert content requirements is the enterprise’s responsibility

Hostname/FQDN support (e.g. SIP server ID)Internal/External IP support (e.g. PPM server ID)Cert revocation URISIP domain (RFC 5922) support

Use only Public PKI CA (no System Manager, no Enterprise PKI CA) Use this strategy if the following is true• You know you must manage X.509 Certificates.• Use of third-party certificate management is possible.• You prefer involving a Trusted root CA for certificate renewal.• You do not plan to issue device identity certificates to phones.• You want the public VoIP Client Applications on Windows/OSX/Linux/iOS/Android to trust your VoIP servers “out of the box” without having to manage endpoint device Trust Stores.• All of your VoIP entities are visible to Trusted root CA’s.

39

No SMGR CA – Import CA and ID certs provided by Enterprise PKI

Pros: Provides enterprise branded, enterprise asserted trust.Cons: Currently: Requires manual PKI trust chain distribution to Aura managed elements.

Currently: Requires administrator handling of PKCS12 passphrase and therefore grants access to the unencrypted private key. NOTE: In some cases, CSR’s can be generated on Aura managed elements and manually exported for signing. A similar manual procedure is required to import the signed ID cert.Cannot automatically reissue certs as they near expiration.Deployment to Aura managed elements is manual and more error prone.Meeting NIST requirements is the enterprise’s responsibilityFuture : Meeting Avaya cert content requirements is the enterprise’s responsibility

Hostname/FQDN support (e.g. SIP server ID)Internal/External IP support (e.g. PPM server ID)Cert revocation URISIP domain (RFC 5922) support

Use only Enterprise PKI CA (no System Manager)The PKI Root can be isolated and hardened independent of the VoIP management system. Use this strategy if the following is true:• You know you must manage X.509 Certificates.• Use of third-party certificate management is possible.• You want to reissue certificates when they expire or when their identifying characteristics change without incurring the cost, delay, or complexity of purchasing new public certificates.• There is a risk of losing management control of a server and/or you are required to support Certificate Revocation to alert the remaining servers of a potential bad actor.• You want to isolate your PKI Root and CA functions away from other management functions.

40

OpenSSL is an open source program built into SMGR and it provides a utility to manage basic cryptographic functions.1. Generate a Certificate Signing Request (CSR) and Private Key for SMGR2. Get the CSR signed by the CA 3. Package the signed Identity Certificate and private key into a PKCS#12 archive format 4. Install the third-party trusted Root certificate on SMGR 5. Replace default SMGR Identity Certificate with the third-party signed identity certificate

Generate a Certificate Signing Request and Private Key for SMGR 1. In Public Key Infrastructure (PKI), a Certificate Signing Request (CSR) is a message sent to a CA

containing certain information for a digital identity certificate. 2. As part of the CSR process, a private key and public key (key pair) are created. The public key is

sent as part of the CSR3. The requirements for the Signed certificate for SMGR in this example are as follows; • Naming Convention: x.509 PKI standards. • Key Lengths: 2048 bit • Hash Algorithms: X509 Sha1 or Sha256 (with RSA Encryption) • CN = Fully Qualified Domain Name (FQDN) • Subject Alternative Name (SAN) = FQDN and vFQDN. This value for vFQDN or Virtual Fully Qualified Domain Name can be found on SMGR in $MGMT_HOME/infra/conf/smgr-properties.properties

Edit the OpenSSL Default Configuration File1. It’s not possible to input the Subject Alt Name (SAN) using the basic openSSL interactive prompt as

SAN is part of openSSLversion 3. 2. Instead, it’s necessary to use a configuration file. Avaya recommends entering two DNS Subject

Alternative names. 3. 1st Fully Qualified Domain Name (FQDN) of SMGR and 2nd is used for Geographic Redundancy. 4. The Geo Redundant name is normally the FQDN of SMGR preceded by the letters “gr” + is referred to

as the virtual FQDN or vFQDN.

It is recommended to add a Geo Redundant name, even if SMGR is not configured for Geo Redundancy. In this case, it is not necessary to add the vFQDN to the DNS server. Connect to SMGR using Secure Shell (SSH) for command line (CLI) access. 1. Log into SMGR using SSH connection as admin 2. Switch user to root 3. Make a backup copy of the default openssl configuration file located in following directory: etc/pki/tls/openssl.cnf4. Edit the openssl configuration file.

41

SMGR Self-Signed CA (SMGR-CA) NOTE: This is the default mode for “green field” installs. Use SMGR as the Root CA to create certificates that can replace the non-unique Demo/SIP CA certificates. This strategy is efficient and cost effective for phones, but required certificate installation in Trust stores of Remote ClientsPros: Works “out-of-the-box”.

Automatically reissues and deploys NIST compliant ID certs when they near expiration for all managed Aura elements Avaya manages ID cert content for increased securityFuture: Hostname/FQDN support (e.g. SIP server ID cert)Future: Internal/External IP support (e.g. PPM server ID cert)Future: will automatically manage cert revocationFuture: SIP domain (RFC 5922) support.

Cons: Certs lack enterprise branding – possible issue for federation scenarios if no SBC at edge. Can be overcome only with

manual procedures.YAPKI (Yet Another PKI) for the enterprise to manage (telecom vs IT)

Use SMGR as the Root CA Use this strategy if one of the following scenarios is true.• You do not yet deploy or manage X.509 Certificates within your data network. • You know you must manage X.509 Certificates.• Your VoIP solution is deployed on your data network along with other services.• If use of third-party certificate management is possible.• You want to reissue certificates when they expire or when their identifying characteristics change without incurring the cost, delay, or complexity of purchasing new public certificates.• Direct server management and certificate expiration are allowed to revoke trust. CRL’s and the OCSP protocol for endpoints are not yet fully supported.• You want to consolidate your VoIP PKI CA functions along with your other VoIP solution management functions.• You want an independent PKI Root for your VoIP solution.

42

43

SMGR using Enterprise PKI Intermediate CA This strategy can leverage the installation of the enterprise CA certificate in remote client trust stores and still gain the efficiencies of System Manager Certificate management.

Pros: Provides enterprise branded, enterprise asserted trust.Automatically reissues and deploys NIST compliant ID certs for managed Aura elements when they near expirationAvaya manages ID cert content for the customerFuture: Hostname/FQDN support (e.g. SIP server ID)Future: Internal/External IP support (e.g. PPM server ID)Future: will automatically handle cert revocationFuture: SIP domain (RFC 5922) support.

Cons: Currently: Requires manual PKI trust chain distribution to Aura managed elements.

Enterprise roots usually push to user trust stores on mobile platforms creating problems for multiuser or distributed user environments.

Use System Manager as an Intermediate CA of an Enterprise PKI CA Use this strategy if the following is true:• You know you must manage X.509 Certificates.• Use of third-party certificate management is possible.• You want to reissue certificates when they expire or when their identifying characteristics change without incurring the cost, delay, or complexity of purchasing new public certificates.• Direct server management and certificate expiration are allowed to revoke trust. CRL’s and the OCSP protocol for endpoints are not yet fully supported.• You want to consolidate your VoIP PKI CA functions along with your other VoIP solution management functions.• You want all certificates to descend from your existing Enterprise Root Certificate to simplify management of Trust Stores.

If the customer site doesn’t have SCEP server in PKI system, it can easily setup SMGR as a sub-CA in the system to serve Avaya terminals on certificate management, while SMGR and other Aura server systems can join customer’s PIf the customer site doesn’t have SCEP server in PKI system, it can easily setup SMGR as a sub-CA in the system to serve Avaya terminals on certificate management, while SMGR and other Aura server systems can join customer’s PKI system simply. KI system simply.

44

SMGR using 3rd-Party Intermediate CAPros:

Provides third party vendor assured trust of enterprise i-CA.Automatically reissues and deploys NIST compliant ID certs for managed Aura elements when they near expirationAvaya manages ID cert content for the customerFuture: Hostname/FQDN support (e.g. SIP server ID)Future: Internal/External IP support (e.g. PPM server ID)Future: will automatically handle cert revocationFuture: SIP domain (RFC 5922) support.

Cons:Very expensive and is likely going away.Currently: Requires manual PKI trust chain distribution to Aura managed elements that don’t have intrinsic vendor trust in the OS distro.

45

46

Presence – in 7.0 presence managed by SMGR as part of EDP

ACBE uses Element Manager ServerPresence and AAC don’t have an EMS

47

1. A PKI can contain multiple levels with the root CA at the top level, and intermediate or subordinate CAs at lower levels. One of the subordinate CAs is the issuing CA that the end user contacts for certificate requests.

2. The root CA may be off-line once the intermediate or subordinate CAs are in place. The digital identity certificate issuedin place.

3. The digital identity certificate issued to the end user is linked back to the root CA using a chain of trust.

4. If the cert was not issued by a trusted CA, the connecting device (e.g., endpoint) will then check the CA chain including Intermediate and Subordinate certificates to see if the cert of the issuing CA was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the device will usually display an error).

5. All the CAs (Trusted Root, Intermediate and Subordinate) must be included in the certificate chain to establish mutual authentication between the client and server.

6. The inclusion of server based certificates (Trusted Root, Intermediate and Subordinate and Identity) from the root certificate to the end-user certificate, represents the Certificate Authority chain.

7. If there are any missing pieces authentication will fail

1. Security and trust are established by creating a “chain of trust” from a certificate back to a known certificate issuer (“certificate authority”). There are many well-known certificate authorities (CAs) that have established relationships with operating system and device vendors in order to act as “trusted root CAs”.

2. Each CA has its own identity certificate (a “CA certificate”) which is used as a “trust anchor”; if a certificate can be traced back to one of these trust anchor certificates and passes all of the other validity checks, then it can be used to establish a secure connection and the identity of the bearer.

3. Many organizations have their own in-house CA whose certificate they distribute as an additional trust anchor. 4. Avaya also created a private CA that issued default product certificates for demonstrations, lab purposes, and use in isolated private networks.5. In general, a hierarchy contains multiple CAs with clearly defined parent-child relationships. In this model, the child subordinate certification

authorities are certified by their parent CA-issued certificates. 6. These certificates bind a certification authority's public key to its identity. The CA at the top of a hierarchy is referred to as the root authority, or

root CA. 7. The children CAs of the root CAs are called subordinate or intermediate certification authorities. The following figure shows an example of a CA

hierarchy.8. A PKI can contain multiple levels with the root CA at the top level, and intermediate or subordinate CAs at lower levels. One of the subordinate

CAs is the issuing CA that the end user contacts for certificate requests. 9. The root CA may be off-line once the intermediate or subordinate CAs are in place. 10. The digital identity certificate issued to the end user is linked back to the root CA using a chain of trust.11. A Root CA is the topmost CA in a CA hierarchy. Each CA hierarchy begins with the Root CA, and multiple CAs branch from the Root CA in a

parent-child relationship. 12. All children CAs must be certified by the corresponding parent CA back to the Root CA. The Root CA is kept in a secure area and is usually a

stand-alone offline CA. The root CA provides certificates for intermediate CAs. The certificates can be revoked if they are compromised.13. An Intermediate CA is subordinate to another CA, either a Root CA or another intermediate CA, and issues certificates to other CAs in the CA

hierarchy. Intermediate CAs are usually stand-alone offline CAs similar to Root CAs.14. Issuing CAs provide certificates to users, computers, and other services. There can be multiple issuing CAs. For example, one issuing CA can

generate computer certificates and another can generate user certificates.

48

Avaya Aura® System Manager provides centralized administration and manages many Avaya Aura® components based on secure communications. System Manager Trust Management provisions and manages certificates of various applications, such as servers and devices, and provides secure inter-element communication. The certificates for System Manager and Unified Communications Manager (UCM) are managed through the System Manager web interface.

Certificates issued by SMGRIn the context of SMGR and SM, the certificate that is used to assert its identity is called a product certificate or an identity certificate. The issuer or CA certificate used by SMGR and SM to verify and validate the identity of the far end is referred to as the trusted certificate or root CA certificate.

TLS sessions use a client-server model.1. Clients (i.e., devices requiring a service) contact a server and are offered an identity certificate as proof of the server’s

integrity. 2. Clients verify the offered certificate by testing authenticity with a common trusted root CA certificate. 3. If successfully authenticated; the client and server commence negotiations on an encryption scheme, 4. and if successful, transmission is secured from that point. 5. SMGR can act as a certificate authority similar to VeriSign and Symantec.6. Many adopters, such as CM, SM, and Presence, already use certificates issued by SMGR.7. For fresh installations, all Identity Certificates, including SIP and HTTPS, are issued by the SMGR CA.

You must install the SMGR trusted root certificates on endpoints that communicate with SM over TLS for the endpoints to trust the SM identity certificate.

Use this checklist for using the Identity Certificates issued by the SMGR.1. Export the SMGR CA. 2. Add the Root Certificate of the System Manager to CM.3. Add SMGR Root Certificate to 96xx phones. 4. Add the SMGR Root Certificate to any other SIP connections, such as CS1K and Radvision. 5. Replace the SM SIP and HTTP Identity Certificates. Note: You must perform this step for all SM and Branch Session Manager Servers. 6. Remove the SIP CA Root Certificate from all trust lists, such as Communication Manager and phones. Other Session Manager servers

administered under the same System Manager will already trust the new Identity Certificate.

In Public Key Infrastructure (PKI), a Certificate Signing Request (CSR) is a message sent to a CA containing certain information for a digital identity certificate.

As part of the CSR process, a private key and public key (key pair) are created. The public key is sent as part of the CSR1. Generate a Certificate Signing Request (CSR) and Private Key for SMGR2. Get the CSR signed by the CA 3. Package the signed Identity Certificate and private key into a PKCS#12 format 4. Install the third-party trusted Root certificate on SMGR 5. Replace default SMGR Identity Certificate with the third-party signed identity certificate

49

50

Session Manager 6.3.x and Branch Session Manager 6.3.x (BSM) are identical in terms of certificate management. The certificate operation for Session Manager is performed through System Manager and applies to Session Manager 7.0 and Branch Session Manager 7.0 as well.

Only SM will be discussed here, but the same principles will apply to the BSM. Session Manager’s certificate operation should be performed through SMGR.

System Manager and all Session Managers must have their certificates modified at the same time.

Avaya recommends using the System Manager Certificate Authority to issue unique Certificates for Session Manager.

An example would be using TLS SIP trunks to connect Avaya Aura® Communication Manager or Avaya Aura® Session Border Controller for the Enterprise. Another option is to use third-party certificates issued by trusted Certificate Authorities such as Verisign.

As of Session Manager Release 6.3.8, Avaya no longer ships default certificates, also known as Demo certificates, with new installations of Session Manager. Demo certificates are not secure. However, Demo certificates are retained when upgrading from a previous Session Manager release. Use the CLI command initTM –d or initTM --demo to revert back to the demo certificate.

Each Session Manager interface can only support one Identity Certificate. The newer installed certificate replaces the currently existing certificate.

The imported certificate file must be in the PKCS12 format. The CA has to generate a private and public key pair, as well as a certificate for Session Manager.

CSR generation is currently not supported using the Inventory page on System Manager. Generate CSRs using OpenSSL or other adequate tool.

The PKCS12 file may also contain the trust chain for the CA that issued the Session Manager identity certificate. Older versions of System Manager require that this trust chain be installed first in the trust store before installing the identity certificate in this step.Currently, if a third-party certificate is applied to the security module_sip interface; all the secure connections over this interface will use the third-party certificate for authentication. For example, SIP/TLS will both use this certificate. You cannot apply different certificates for different SIP applications at this time.

51

The common method for securing the integrity and confidentiality of the protocols used by Avaya products is TLS. TLS will be used to secure the communication channel to prevent eavesdropping and message tampering. In addition, credentials used to establish these TLS sessions may be leveraged to provide element-level authentication and authorization.

Identity (endpoint or server) and Trusted (Root) Certificates are integral in establishing such TLS sessions. PKI (Public KeyInfrastructure) is a commonly used and scalable technology to facilitate provisioning and remote management of these certificates and establish trust domains for a deployment.

Once digital certificates have been deployed to the various network elements, an additional layer of access control (authorization) is recommended in addition to the TLS authentication provided by the digital certificates. This access control is implemented byspecifying trust relationships using Trusted Host Lists (THL).

These trust relationships are similar to access control lists that use IP addresses to specify which entities (clients, servers or applications) are allowed to connect to a given interface. However, instead of using IP addresses to specify trust relationships, Trusted Host Lists that use the fields from a digital certificate’s subject name, subject alternative name, or issuer names will be used. These lists contain the names to specify which hosts, applications or entities are allowed to connect to a given application interface or entity. These names are usually in the form of a Fully Qualified Domain Name (FQDN) and are checked against the provisioned Trusted Host list.In some cases Trusted Hosts are also granted authorization to perform privileged operations. For example, in Avaya Aura® TrustedHosts are allowed to assert identity in a P-Asserted-Identity header.

TLS Layer validation Security Design in Avaya Aura® Session Manager Release 6.3 2013 Use of Cryptographyhttps://downloads.avaya.com/css/P8/documents/100168178Session Manager applies the following validations for SIP TLS connections:1) Mutual TLS authentication: During the TLS handshake, the SIP entity and Session Manager validateeach other certificate and perform mutual TLS authentication.2) Additional validation of the SIP entity identity certificate: If mutual TLS authentication issuccessful, further validation is performed using the credential name or the far end IP address ofthe SIP entity identity certificate.a. If the credential name string is empty, the connection is accepted.b. If the credential name string is not empty, the credential name and the IP address of theSIP entity is searched at following places in the identity certificate provided by the SIPentity.i. CN value from the subjectii. subjectAltName.dNSNameiii. subjectAltName.uniformResourceIdentifier. For IP address comparison, the IPaddress string is converted to SIP:W.X.Y.Z before comparison. W.X.Y.Z is theremote socket IPV4 address. Also case insensitive search is performed in thiscase.3) On the Session Manager Administration page, an administrator can enable or disable TLSendpoint certificate validation feature.

52

53

54

55

56

Session Manager 6.3.x and Branch Session Manager 6.3.x (BSM) are identical in terms of certificate management. The certificate operation for Session Manager is performed through System Manager and applies to Session Manager 7.0 and Branch Session Manager 7.0 as well.

Only SM will be discussed here, but the same principles will apply to the BSM. Session Manager’s certificate operation should be performed through SMGR.

System Manager and all Session Managers must have their certificates modified at the same time.

Avaya recommends using the System Manager Certificate Authority to issue unique Certificates for Session Manager.

An example would be using TLS SIP trunks to connect Avaya Aura® Communication Manager or Avaya Aura® Session Border Controller for the Enterprise. Another option is to use third-party certificates issued by trusted Certificate Authorities such as Verisign.

As of Session Manager Release 6.3.8, Avaya no longer ships default certificates, also known as Demo certificates, with new installations of Session Manager. Demo certificates are not secure. However, Demo certificates are retained when upgrading from a previous Session Manager release. Use the CLI command initTM –d or initTM --demo to revert back to the demo certificate.

Each Session Manager interface can only support one Identity Certificate. The newer installed certificate replaces the currently existing certificate.

The imported certificate file must be in the PKCS12 format. The CA has to generate a private and public key pair, as well as a certificate for Session Manager.

CSR generation is currently not supported using the Inventory page on System Manager. Generate CSRs using OpenSSL or other adequate tool.

The PKCS12 file may also contain the trust chain for the CA that issued the Session Manager identity certificate. Older versions of System Manager require that this trust chain be installed first in the trust store before installing the identity certificate in this step.Currently, if a third-party certificate is applied to the security module_sip interface; all the secure connections over this interface will use the third-party certificate for authentication. For example, SIP/TLS will both use this certificate. You cannot apply different certificates for different SIP applications at this time.

57

The common method for securing the integrity and confidentiality of the protocols used by Avaya products is TLS. TLS will be used to secure the communication channel to prevent eavesdropping and message tampering. In addition, credentials used to establish these TLS sessions may be leveraged to provide element-level authentication and authorization.

Identity (endpoint or server) and Trusted (Root) Certificates are integral in establishing such TLS sessions. PKI (Public KeyInfrastructure) is a commonly used and scalable technology to facilitate provisioning and remote management of these certificates and establish trust domains for a deployment.

Once digital certificates have been deployed to the various network elements, an additional layer of access control (authorization) is recommended in addition to the TLS authentication provided by the digital certificates. This access control is implemented byspecifying trust relationships using Trusted Host Lists (THL).

These trust relationships are similar to access control lists that use IP addresses to specify which entities (clients, servers or applications) are allowed to connect to a given interface. However, instead of using IP addresses to specify trust relationships, Trusted Host Lists that use the fields from a digital certificate’s subject name, subject alternative name, or issuer names will be used. These lists contain the names to specify which hosts, applications or entities are allowed to connect to a given application interface or entity. These names are usually in the form of a Fully Qualified Domain Name (FQDN) and are checked against the provisioned Trusted Host list.In some cases Trusted Hosts are also granted authorization to perform privileged operations. For example, in Avaya Aura® TrustedHosts are allowed to assert identity in a P-Asserted-Identity header.

TLS Layer validation Security Design in Avaya Aura® Session Manager Release 6.3 2013 Use of Cryptographyhttps://downloads.avaya.com/css/P8/documents/100168178Session Manager applies the following validations for SIP TLS connections:1) Mutual TLS authentication: During the TLS handshake, the SIP entity and Session Manager validateeach other certificate and perform mutual TLS authentication.2) Additional validation of the SIP entity identity certificate: If mutual TLS authentication issuccessful, further validation is performed using the credential name or the far end IP address ofthe SIP entity identity certificate.a. If the credential name string is empty, the connection is accepted.b. If the credential name string is not empty, the credential name and the IP address of theSIP entity is searched at following places in the identity certificate provided by the SIPentity.i. CN value from the subjectii. subjectAltName.dNSNameiii. subjectAltName.uniformResourceIdentifier. For IP address comparison, the IPaddress string is converted to SIP:W.X.Y.Z before comparison. W.X.Y.Z is theremote socket IPV4 address. Also case insensitive search is performed in thiscase.3) On the Session Manager Administration page, an administrator can enable or disable TLSendpoint certificate validation feature.

58

If your 6.1 System Manager has been running for nearly 2 years and you can no longer log into System Manager and you get a strange message which looks something like this after you login pages/Welcome.xhtml @70/67 value=”” …… or possibly all your SIP endpoints/trunks have died then your certificates may have run out they have to be renewed every two years or are automatically done when you upgrade.See Avaya PSN’s for full details but a summary of events are below;PSN003661u System ManagerPSN003617 Session ManagerSYSTEM MANAGERIn affect you have to download CertificateRenewalUtility.bin from the Avaya support site and upload it to the system manager either using winscp of via sftp to the /tmp directory on System Manager then cd /tmp and run sh CertificateRenewalUtility.bin you should now find you can login to System Manager correctly although I found I had to restart JBOSS on System Manager “service jboss restart”.SESSION MANAGERNow for Session Manager so log on via the command line, you need root access.From the Session Manager command line su – sroot and provide the root password Change directory to the following path: cd /opt/Avaya/SIPAS/current/ServiceDirector/tm/external/keystores Type ls -ltr and hit enter, this will show two entries: -rw—- 1 root root 1984 Feb 16 13:53 system_manager_external_keystore.jks-rw—- 1 root root 1984 Feb 16 13:53 sd1_external_keystore.jksRun the following command and hit enter : echo | keytool -list -v -keystore sd1_external_keystore.jks 2>&1 | grep -m 1 ValidCheck the validity of the certificate to make sure it has not expired. Take note of all the expiration dates for reference:(Valid from: Thu Feb 16 13:43:17 MST 2012 until: Sat Feb 15 13:43:17 MST 2014)Run the following command to check the second keystore and hit enter:echo | keytool -list -v -keystore system_manager_external_keystore.jks 2>&1 | grep -m 1 Valid Now run the following command to check the Jboss certificate and hit enter:echo |keytool -list -keystore /opt/jboss/server/*/conf/tm/keystore/container_keystore.jks -v 2>&1|grep -m 1 ValidIf all the certificates expiration dates are in the future, no immediate action is requiredIf any of the certificates are about to expire (but not yet expired) and Session Manager is release 6.0.x or 6.1.x, perform the following steps to renew these certificates:The following procedure is service affecting and needs to be schedule and executed within the change control guidelines specific to every customer. Approximate outage time required is between 10-30 minutes.From the System Manager Webpage underHome/Elements/Session Manager, select the Session Manager and change the service state to “Deny New Service” ;wait until the active call count is close to zero TMClientInv.xml file: rm -f /opt/Avaya/jboss-4.2.3.GA/server/s*/conf/tm/TMClientInv.xml Run #initTM from the Session Manager command line, providing the enrollment password obtained from System Manager webpage under : Home/Services/Security/Certificates/Enrollment Password Place the Session Manger back in “Accept New Service” from the System Manager WebpageThe process will then continue without further intervention and once completed, all the certificates will now be valid for a minimum of two years

Renewal of expired or about to expire certificates of Avaya Aura® System Manager https://downloads.avaya.com/css/P8/documents/100159923This PSN is applicable to all System Manager Installations which has not been upgraded for almost last two years and has expired orabout to expire certificates.This PSN renews following:1. Expired certificates of System Manager2. Expired System Manager Database certificates.3. If needed customer can also renew about to expire certificates.

Avaya Aura Session Manager: Releases 1.1.x, 5.2.x, 6.0.x, 6.1.x and 6.2.0https://downloads.avaya.com/css/P8/documents/100157898Session Manager uses several internal ID certificates to authenticate TLS connections within its internal components and with externalentities (i.e. SIP TLS, Jboss mgmt, etc.). Some of these certificates expire within two years from the original installation date. ThisPSN describes the procedure to renew these certificates in the affected releases outlined above. PLEASE NOTE THAT FAILURETO FOLLOW THE BELOW PROCESS COULD RESULT IN A COMPLETE SYSTEM OUTAGE SHOULD THECERTIFICATES EXPIRE.Avaya strongly recommends upgrading all Session Manager and System Manager servers to release 6.3 to take advantage of severalnew features including enhanced alarming capabilities and automatic renewal of all Avaya certificates without the need for customerintervention.ResolutionPlease note that this PSN should be implemented only after you have completed the System Manager Certificate renewal procedureoutlined in PSN003661 u available on Avaya’s support site.

59

Important: Make sure the ip-codec-set administration on Communication Manager is correct for various ip-network-regions to insure SRTP communication is enforced. You must configure the Communication Manager so that all RTP traffic is encrypted.

Communication Manager uses five unique certificates for different interface TLS connections with different outside entities such as Session Manager and LDAP server.Communication Manager certificates are managed using the Communication Manager System Management Interface (SMI) web pages.

60

Use System Manager Root CA Internally with Public PKI CA ExternallyThe Public PKI vendor issues and revokes certificates and approves all renewals, but only for public-facing servers such as ASBCE. There is no need to manage Trust Stores of Remote clients. Internal Certificates are managed internally. This solution is complex to manage for mobile clients that switch from internal to external connectivity.Use this strategy if the following is true:• You know you must manage X.509 Certificates.• Use of third-party certificate management is possible.• You prefer involving a Trusted root CA for certificate renewal.• You do not plan to issue device identity certificates to phones.• You want the public VoIP Client Applications on Windows/OSX/Linux/iOS/Android to trust your VoIP servers “out of the box” without having to manage endpoint device Trust Stores.• You VoIP entities have internal network identities that are not verifiable by Trusted root CA’s.• Your internal VoIP solution can be self-managed, but you want your VoIP devices deployed externally to perform server certificate validation only against Trusted Root CA certificates loaded in the device OS or application.

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102