Avaya Aura Security Certificates Demystified

Avaya Aura Security Certificates Demystified
RMAUG May 2016 Sandy Abramson Avaya – Confidential & Proprietary Use pursuant to your agreement or Avaya policy

Why do we need to talk about Certificates ?
Avaya products are using Digital Certificates for some time. Non-unique Avaya SIP Product CA Certificates were used previousely acrosss products to provide out-of-box lab/demo/default support for TLS. The Avaya Default certificate is a SHA1/1024 identity certificate no longer meets current NIST standards. New greenfield installations do not come with default CA certs New SM servers no longer use the Avaya “SIP Product CA” issued Default Certificates. The new generation of Avaya Communicator Clients will no longer trust demo Certificates and require servers to have certificates issued by a trusted CA in order for the client to establish a secure connection. A new CA certificate must be created via SMGR EJBCA (recommended), Enterprise (Private) CA, or a third party trusted root authority. The Default certificate that came with each product should be upgraded. All products deployed in an enterprise must be on the same secure hash algorithm and bit size key across a solution i.e., – SHA or SHA2 2048 This talk provides guidance for migrating Avaya provided demonstration grade certificates to customer self-signed or trusted root 3rd party digital certificates. 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. 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. Why is this happening - as with other forms of identification, certificate technology has progressed over the years. 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. 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. The default certificates shipped with Avaya Aura Session Manager were intended for lab and demonstration use only. Up to now, products have included support for these default certificates to facilitate lab testing. Removing support for these default certificates from the products allows a customer with higher security needs to implement a strategy using current best practices. Avaya Aura® 6.2.x Feature Pack 1st release to officially support SHA2/204 certificates. SHA-1 A 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. 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? 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). In TLS, servers are configured with an identity certificate issued by a certificate authority. When products 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. Enhanced security is the overall motivator for migrating from demo to third party signed certificates. This is achieved by deploying certificates with shorter validity, enhanced key length, stronger signing algorithms and a trusted issuing authority. A Digital Certificate serves as a guarantee that the parties to a transaction are who they claim to be. The certificate consists of a long string of binary code issued by a certification authority (CA). The CA authenticates the parties' identities and creates a public key for message encryption, and a private key for message decryption. A Digital Certificate does not imply anything about the transaction itself. 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. 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. 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. 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.

Why do we need to talk about Certificates Continued?
Default Certificates are not considered secure for a production environment, and therefore new SM servers no longer use the Avaya “SIP Product CA” issued Default Certificates. The new generation of Avaya Communicator Clients will no longer trust Default Certificates and require servers to have certificates issued by a trusted certificate authority in order for the client to establish a secure connection. Product Support Notice: PSN004253u, PSN004246u, PSN004251u Default Certificates 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. 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. 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. Product Support Notice: PSN004253u, PSN004246u, PSN004251u

Industry is moving SHA-1 encryption to the vastly more secure SHA-2
The longer you wait, the less time you'll have to do it without panicking. Over the coming years, particularly this one and next, many digital-certificate- consuming devices and applications will begin to display warnings/errors or operationally fail if a digital certificate containing the SHA-1 (or earlier) hash is presented. Why the change? Because the SHA-1 hash has been shown to suffer cryptographic weaknesses to the point where many experts think its days of useful protection are numbered. Of course, SHA-1 is the most common hash today, and many applications and devices don’t yet accept or understand SHA-2-related hashes or certificates. There's the rub. Intro to SHA SHA-1 was designed by the NSA and published as a federal standard in Hashes are used for digitally signing content for integrity validation and are a part of any digital certificate. Without cryptographically sound hashing algorithms, digital authentication and integrity would be very hard to do, if not impossible. In 2002, SHA-2 became the new recommended hashing standard. SHA-2 is often called the SHA-2 family of hashes because it contains many different-size hashes, including 224-, 256-, 384-, and 512-bit digests. When someone says they are using the SHA-2 hash, you don’t know which bit length they are using, but the most popular one is 256 bits (by a large margin). Although SHA-2 is constantly attacked and minor weaknesses are noted, in crypto-speak, it's considered "strong." Without question, It's way better than SHA-1, which experts believe will be fallible in the near term. Industry is moving SHA-1 encryption to the vastly more secure SHA-2

SHA-1 deprecation handling
No surprise that many software vendors, especially those with browsers (which consume most of the digital certificates we use today), are actively moving to SHA-2. Expect most Internet browsers to display warning messages or errors soon. Here's a decent summary of the major browser vendors' position statements. Each vendor will handle matters differently, but devices will move slower than software products, simply because software is easier to upgrade. Of course, in many cases, the software with which you access the hardware device will dictate the SHA migration. For example, the LogRhythm event log appliance requires Google’s Chrome browser for access and management -- and Chrome is moving to SHA-2. Starting this year, Google’s Chrome browser will simply show a warning indicator for SHA-1 certificates with validity dates past Jan. 1, For certificates with validity dates past Jan. 1, 2017, there will be a warning, plus the protected content will be treated as mixed content, which will require additional user interaction. Microsoft has announced an even more aggressive stance: SHA-1 deprecation handling

SHA-1 deprecation handling
There will be separate timelines for discontinuing SHA1-based SSL and code signing end-entity certificates … CAs must stop issuing new SHA1 SSL and Code Signing end-entity certificates by 1 January 2016 … For SSL certificates, Windows will stop accepting SHA1 end-entity certificates by 1 January This means any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017 … For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016. S HA1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack. Check with vendor of your browser of choice for more details. It’s expected that most public CAs (Certification Authorities) will no longer issue SHA-1- based certificates with useful lives beyond Jan. 1, Everything after will be SHA-2. If you currently have a public-facing website with an SHA-1 Web certificate, you’ll most certainly want to upgrade to SHA-2 before that date. Unfortunately, the move from SHA-1 to SHA-2 is a one-way operation in most server scenarios. For example, once you move your Web server’s certificate from SHA-1 to SHA-2, clients that don’t understand SHA-2 certificates may see warnings or errors -- or fail. SHA-2 migration will be a risky jump for unsupported applications and devices. SHA-1 deprecation handling

Public Key Infrastructure Overview
1

Introduction to Access Control Policy
To be able to access data and applications from within a company, a user first needs to be authenticated, and then needs to be authorized to perform the operation. Authentication Procedures perform the former task, and Access Control Decision functions perform the later task.

Password Authentication
When a company has several applications hosted by different systems and servers, there are several ways of identity authentication. Multiple passwords, one for each system/application Same password, replicated in each system Single sign-on software Directory Server

Symmetric and Asymmetric Encryption
The objective of encryption is to transform a message to a cipher text, ensuring confidentiality In the symmetric encryption schemes the same key (called the secret key) is used to both encrypt and decrypt the text. Ex :- DES algorithm. Asymmetric cryptosystems use one key (the public key) to encrypt a message and a different key (the private key) to decrypt it. Ex:- RSA and ECDSA algorithms.

Contd… Comparison between symmetric and asymmetric encryption

Hashing Hashing is the method used to obtain a "digital fingerprint" (hash) for a given message. The hash code has a fixed-length (normally 128 or 160 bits) and it's designed to be unique Some examples are MD2, MD4, MD5 (128 bits) and SHA1 (Secure Hash Algorithm,160 bits ) SHA2 256 bits

Digital Signature To obtain a secure digital signature,
At first the message is hashed creating a digital fingerprint which is encrypted using the receiver's public key Creating a digital signature. The clear message is combined with the digital signature The result (an authenticated message) is sent After the reception, the message is separated from the digital signature which is decrypted using the receiver's private key The message is hashed into a "temporary" digital fingerprint which is used to validate the received fingerprint If the message has not been modified during the transfer process, it's authenticated.

Mechanism of Digital Signature

Public Key Infrastructure
Three different formats of messages can be used in public-key cryptosystems: Encrypted message, Signed message, Signed and encrypted message. An infrastructure must be set-up to allow them to be undoubtedly trusted , as they are accessible via unsecured networks (Internet) PKI entities: -CA ( certification authority ) -RA ( registration authority ) -Subscriber -Relying Party -Repository

PKI basic entities and operations

Certification Certification is the fundamental function of all PKIs. The certificates provide a secure way of publishing public keys, so that their validity can be trusted. A certificate contains (at least) the basic information needed to provide a third party entity with the subject's public key: • Subject Identification information • Subject public Key • CA Identification Information • Validity (e.g. time)

Certification contd... Cross certification :- Not all the entities will trust the same CA to hold their certificates. Cross certification is used to create the certificate between two CAs. If both CAs trust each other, a cross certificate pair is established. In other cases, only one certificate would be created, and not a pair.

Certification contd... Certification path :- In a universe composed of several different CAs an arbitrary number of CAs must validate each other, until a certificate is obtained. This process is called certification path validation.

Validation This is the process that ensures that the certificate information is still valid, as it can change over time. Either the user can ask the CA directly about the validity - every time it's used - or the CA may include a validity period in the certificate. This second alternative is also known as offline validation.

Revocation This is the process of informing the users when the information in a certificate is not valid. This is especially interesting in the absence of online validation approaches, and the most common revocation methods consist in publishing Certification Revocation Lists (CRL). A CRL is a "black" list of revoked certificates that is signed and periodically issued by a CA.

Authentication In order for the subject to gain access to its private key, it has to possess a smart card or an encrypted key file and know something (PIN or password) or be something (e.g. a particular fingerprint).

Keys Key pair models :- To increase the security level, different key pairs might exist for different functions, which may be divided into the following categories: • Non-repudiatable message signing (e.g. ). • Encryption/Decryption functions. • Authentication only (e.g. LOG ON functions).

Key Management These are the main steps performed in a PKI structure to handle the key pairs: •Key Generation •Storage of Private Keys •Revocation of Public Keys •Publication of certificates and CRL •Key Update •Backup / Recovery •Escrow / Recovery

Migration plan The hardest part of an SHA-2 migration project is determining which devices and applications work with SHA-2. If the consuming devices don’t understand SHA-2, expect failure or an error message -- which probably won't be as enlightening as “SHA-2 unrecognized.” Instead, brace yourself for: “Certificate not recognized,” “Connection not sure,” “Connection can’t be established,” “Bad certificate,” or “Untrusted certificate.” Think of your mission to determine what will or won't work as a kind of mini-Y2K project. Start by trying to inventory every unique device, OS, and application that will need to understand SHA-2. Then put together a team of people to test whether SHA-2 works. You can tentatively rely on vendor attestations, but until you test using a SHA-2 certificate, you won’t know for sure. Upgrading your applications and devices will not be trivial and probably take longer than you think. Even now, I see a ton of devices and applications running older versions of OpenSSL, which should have been patched following Heartbleed, but were not. Remember, too, that upgrading requires formal user testing and acceptance. If you have an internal PKI (public key infrastructure), you’ll need to prepare it for SHA-2 as well. Sometimes that means upgrading your CAs, getting new CA certs, or installing entirely new PKIs. I recommend the last for a lot of reasons, mostly because a new PKI gives you a chance to start again, free of past mistakes. Migrating from SHA-1 to SHA-2 isn’t hard technically, but it’s a massive logistical change with tons of repercussions and requires lots of testing. It's a lot easier to do over six months or two years than in a rushed panic at the end of 2016. I don’t think most vendors know the ultimate kill date for SHA-1, but I would guess it will arrive as more and more consumers move to SHA-2. I’ve already seen lots of customers doing this, so avoid being caught up short.

Session Manager Default Certificates changes with FP4
To enhance security, we have changed the default certificates used on new SM installs. Previous SM releases defaulted to test/demo certificates to facilitate ease of evaluation with other Aura elements and endpoints in a customer test bed. These legacy certificates were issued by the Avaya SIP Product CA. NOTE: Avaya has long advised customers against use of these legacy test/demo certificates in production environments. We are now changing install defaults to further discourage their use in production. On new SM installs, SM will default to NIST SP A compliant identity certificates issued by SMGR-CA. The default SIP & PPM trust domains will no longer include the legacy Avaya SIP Product Certificate Authority. On SM upgrades the SM will still inherit its previous ID certificates and SM/PPM trust stores. This decouples SM release upgrades from upgrades of the SM network to NIST certificates.

Session Manager Default Certificates changes with FP4 Continued
To support setups where new SMs (i.e., new installs) are added to existing networks that use previous ID certificates, we provide existing customers a method to augment SMs in their lab test beds. FP4 SM servers can use new “initTM –d” option to install legacy test/demo certificates and the Avaya SIP Product CA trust domain. However, we strongly encourage upgrading to NIST SP A compliant certificates. Support for third party identity certificates has not changed. The ability to use a third party intermediate CA on SMGR has not changed although it will issue NIST certificates with SMGR FP4. Use Case: Legacy test/demo/default Identity certificates are insecure and should never be used in production. Customers can still add/replace an SM server in their test bed and use the older deprecated test/demo certificates. However the method for accessing these certificates will present an advisory warning message. New customer networks will be NIST SP A compliant by default using the SMGR’s certificate authority.. Existing customers have SM and SMGR support to migrate to SMGR-CA issued NIST SP A certificates

What Services are affected ? Communicator Example
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. The color coding of each element reflects the issuing certificate authority for certificates presented by that element (see the legend for details). Elements which may have certificates from multiple authorities are shown using a gradient fill. 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. 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. 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. 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. 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. Session Manager SIP and HTTPS (PPM) connections are most important because these certificates communicate with outside entities such as Communication Manager and SIP endpoints.

Example affected network elements + connections
Example drawing Certificate based links

Example links

Public Key Infrastructure (PKI) & Certificates
Certificates bind an identity to a public key. The Certificate Authority (CA) is a trusted third party, responsible for verifying the identity of a user and issuing a tamper resistant digital certificate for applicants. The digital certificate is digitally signed data stating that the public-key included in the certificate belongs to the user identified by the certificate. The certificate signature is created by the issuing CA and can only be validated with the issuing CA certificate. The signature is a hash of the certificate content which has been encrypted using the issuer’s private key. The issuer’s public key must be used to decrypt the signature to extract the hash. Fundamentals Certificate Authority (CA) 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. 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: - Certificate Authority (CA) that both issues and verifies the digital certificates. - Registration Authority that verifies the identity of users requesting information from the CA. - Secure location in which to store and index keys. - Certificate management system. - 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: - 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. - 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. - 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. - 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.

Trusted Certificate versus Identity Certificate
Identity Certificate and Trusted Certificate are two terms to distinguish the role of a certificate. Identity Certificate is a certificate used to identify an application, an interface, or a device. An identity certificate is presented to the far end as a TLS connection is being established in order to identify the sender of this certificate. Identity Certificate XXXXXXX Signed by: X SMGR root CA Signed by: Root Certificate Trusted certificate is used by the local system to verify the authenticity of an identity certificate received from the far end on a TLS setup.

Typical Use Cases for Certificates
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 X 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 X 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. Signing of software packages to prove the identity of the software publisher and protect against tampering. Establish a secure, authenticated TLS/HTTPS connection between two entities (client and server). EAP-TLS based authentication for 802.1x.

Secure Communication via TLS
All communications between the client and the servers in the Avaya Aura environment can be secured using Transport Layer Security (TLS) protocol. 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. If the validation succeeds, a secure connection is established. Server Authentication Mutual Authentication

Certificate Based Key Exchange

Migration Workflow from Default Certificates
Gather customer requirements. Gather network and architecture documentation. Selection of Certificate Authority. Discuss pros and cons with the customer. Survey of affected network elements and their interconnections. Identify elements of the network that need to be upgraded to support new certificates Develop the migration planning documentation. _abcde_efghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv Ensure that the certificate authority (CA) issuing identity certificates is trusted throughout the network. Generate Certificate Signing Requests (CSR) for each server´s certificate. Get the CSR´s signed by the CA. On each server, install the new server identity certificate. Audit Phase Deployment Phase

Selection of a Certificate Authority
SMGR as Root CA What SMGR certificate management private key infrastructure do I want to adopt? Five choices: SMGR Self-Signed CA (SMGR-CA) - default SMGR Using Enterprise PKI Intermediate CA SMGR Using 3rd-Party Intermediate CA No SMGR CA – Import CA and ID Certs Provided by Enterprise PKI No SMGR CA – Import CA and ID Certs Provided by 3rd-Party PKI What NIST compliant certificates will I use for non-Avaya elements? What NIST compliant certificates will I use for Avaya elements that are not wired into the SMGR PKI (e.g. CM)? 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 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? 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? 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. 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. 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? 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? 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? SMGR as SUB CA Enterprise PKI 3´Party Public PKI

CA Hierarchy Root CA: The topmost element in the PKI hierarchy. It is often provided by a 3rd party vender e.g., Verisign. Root CA (e.g., Verisign) Intermediate CA (Optional): Used for better manageability. Placed to avoid direct interaction with the Root CA. Intermediate CA -1 (e.g., Verisign Class x) Intermediate CA -n (e.g., Verisign Class n) 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. Each CA hierarchy begins with the Root CA, + multiple CAs branch from the Root CA in a parent-child relationship. Child CAs of the root CAs are called subordinate/intermediate certification authorities. See figure. In this model, the child subordinate certification authorities are certified by their parent CA-issued certificates. These certificates bind a certification authority's public key to its identity. 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 Root CA is kept in a secure area and is usually a stand-alone offline CA. The digital identity certificate issued to the end user is linked back to the root CA using a chain of trust. 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. 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. 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. Enterprise CA aka SubCA: CA used by customers for their internal deployments. EJBCA will appear at this level. Enterprise CA -1 (e.g., EJBCA) Customer deployment. Enterprise CA -n (e.g., EJBCA) Customer deployment. Enterprise CA -x (e.g., EJBCA) Customer deployment.

Types of Certificate Authorities (1)
Public CA A well-known and trusted Public CA issues the certificates. Pros: Save time and resources, Computing devices already trust well known CA´s. No need to manage Trust stores. Cons: Requires manual PKI trust chain distribution to Aura managed elements. Manually export of Certificate Signing Request (CRS) and import of the signed Identity Certificate (Optional PKSC12). No automated re-issue of Certificates that are near expiration. Expensive and inflexible if managed elements change in a way that’s affects Certificate content. Complex to issue device identity certificates to Deskphones Commercial CA´s (starting in November 2016) will no longer provide certificates with IP addresses for private networks. 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 responsibility Future : 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 URI SIP 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.

Enterprise (Private) CA The Enterprise creates and operates its own CA to issue the Certificates. Pros: Provides enterprise branded and enterprise asserted trust. PKI trust chain might be already distributed to PC´s and Smart Devices. Cons: Requires manual PKI trust chain distribution to Aura managed elements. Manually export of Certificate Signing Request (CSR) and import of the signed Identity Certificate (Optional PKSC12). No automated re-issue of Certificates that are near expiration. 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 responsibility Future : 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 URI SIP 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.

Deploying Third-Party CA Identity Certificates
Leverage the OpenSSL Utility to generate a Certificate Signing Request and Private Key. Edit the OpenSSL Default Configuration File to include Certificate extension attributes not available via the OpenSSL interactive prompt. The following command generates the keys & a corresponding CSR. Get the CSR signed by the CA. Package the signed Identity Certificate and private key into a PKCS#12 archive format. Install the third-party trusted Root certificate. Import the PKCS #12 file and install the third-party signed identity certificate (key import password required). OpenSSL is an open source program built into SMGR and it provides a utility to manage basic cryptographic functions. Generate a Certificate Signing Request (CSR) and Private Key for SMGR Get the CSR signed by the CA Package the signed Identity Certificate and private key into a PKCS#12 archive format Install the third-party trusted Root certificate on SMGR Replace default SMGR Identity Certificate with the third-party signed identity certificate Generate a Certificate Signing Request and Private Key for SMGR 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 CSR 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 File It’s not possible to input the Subject Alt Name (SAN) using the basic openSSL interactive prompt as SAN is part of openSSLversion 3. Instead, it’s necessary to use a configuration file. Avaya recommends entering two DNS Subject Alternative names. 1st Fully Qualified Domain Name (FQDN) of SMGR and 2nd is used for Geographic Redundancy. 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.cnf 4. Edit the openssl configuration file.

SMGR Self Signed CA Efficient and cost effective for phones, but requires Certificate installation in trusted store of computing device. Pros: Works “out of the Box”. Independent PKI Root for VOIP solution. High efficient Trust Management of Avaya Aura elements. Automatically Re-issues and deploys NIST compliant Identity Certificates when they are near expiration for all Avaya Aura elements. Consolidate VOIP management functions with VOIP PKI function. Cons: Yet another PKI (for telecom) to manage. Certificates lack Enterprise branding. Trusted Root Certificate not distributed to computing device. 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 Clients Pros: 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 security Future: 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 revocation Future: 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.

System Manager as a Certificate Authority (CA)
System Manager is by default a Root CA (self-signed root certificate) or can be setup as a Sub-CA (from a Third Party Certificate Authority). Uses a third-party open source application, Enterprise Java Beans Certificate Authority (EJBCA) to issue identity and trusted certificates to applications through Simple Certificate Enrollment Protocol (SCEP). System Manager Trust Management provisions and manages certificates of various applications, such as servers and devices, enabling the applications to have secure inter- element communication System Manager generates Certificates using SHA2 as the signing algorithm and 2048 as the default key size.

SMGR using Enterprise PKI Intermediate CA Leverages the installation of the Enterprise CA Certificate in the computing devices trust stores and still gain the efficiency of SMGR Cert management. Pros: Provides enterprise branded and enterprise asserted trust. PKI trust chain already distributed to PC´s and Smart Devices. High efficient Trust Management of Avaya Aura elements. Automatically Re-issues and deploys NIST compliant Identity Certificates when they are near expiration for all Avaya Aura elements. Consolidate VOIP management functions with VOIP PKI function (Independency from Enterprise CA). Cons: Requires manual PKI trust chain distribution to Aura managed elements. Enterprise Security Policy to allow Sub-CA on System Manager. . 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 expiration Avaya manages ID cert content for the customer Future: Hostname/FQDN support (e.g. SIP server ID) Future: Internal/External IP support (e.g. PPM server ID) Future: will automatically handle cert revocation Future: 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 P 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 PKI system simply. KI system simply.

SMGR using 3´Party (Public) Intermediate CA Typically a third party CA such as Verisign. This configuration adds the SMGR CA to the existing PKI hierarchy of the third party CA. The third party CA in such scenarios acts as a Root CA. Pros: Save time and resources, Computing devices already trust well known Certificate Authorities. No need to manage trust stores. Automatically Re-issues and deploys NIST compliant Identity Certificates when they are near expiration for all Avaya Aura elements. Consolidate VOIP management functions with VOIP PKI function. (Independent from Enterprise CA). Cons: Expensive. Enterprise Security Policy to allow Sub-CA on System Manager. Requires manual PKI trust chain distribution to Aura managed elements. SMGR using 3rd-Party Intermediate CA Pros: 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 expiration Avaya manages ID cert content for the customer Future: Hostname/FQDN support (e.g. SIP server ID) Future: Internal/External IP support (e.g. PPM server ID) Future: will automatically handle cert revocation Future: 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.

System Manager as an Intermediate CA (SUB-CA)
System Manager certificate authority as a SUB-CA. Change the default Certificate Authority (CA) that the system generated during the System Manager installation to an externally signed Sub CA. Adds SMGR CA to an existing CA hierarchy in the customer environment. Detailed documentation “Administering Avaya Aura® System Manager” Add a new CA via System Manager Web Console Make Certificate Request Sign Certificate from 3´Party CA (Signed request with X509 Extension CA:True) Receive Certificate Response and activate CA as default CA System Manager must have all its identity certificates updated so that they are signed by the new CA, and the new CA must be in the trust stores. Run trust initializer Script Confirming identity certificate updates on System Manager Considerations for existing deployments: The third party Root CA must be first added to the trust store of Applications/Devices. Element Re-registering with SMGR or force elements to request new certificates.

System Manager Trust Management
System Manager supports two modes of trust management Unmanaged Elements Managed Elements Client initiated to request a unique identity certificate during installation/ initialization of the Application. SMGR has no knowledge of the current certificates present and cannot manage the certificates. Performs installation/initialization in the same manner as the unmanaged mode. The application registers then as an element in System Manager and their certificates can now be managed from the System Manager console. Presence – in 7.0 presence managed by SMGR as part of EDP ACBE uses Element Manager Server Presence and AAC don’t have an EMS Presence Services, AAC Session Manager, EDP

CA Hierarchy and CA Chain Management
PKI Intermediate CA Subject CA End-Entity CA for End-Entity Trust Anchor Relying Party Root CA 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 in place. The digital identity certificate issued to the end user is linked back to the root CA using a chain of trust. 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). All the CAs (Trusted Root, Intermediate and Subordinate) must be included in the certificate chain to establish mutual authentication between the client and server. 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. If there are any missing pieces authentication will fail 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”. 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. Many organizations have their own in-house CA whose certificate they distribute as an additional trust anchor. Avaya also created a private CA that issued default product certificates for demonstrations, lab purposes, and use in isolated private networks. 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. 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. The children CAs of the root CAs are called subordinate or intermediate certification authorities. The following figure shows an example of a CA hierarchy. 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. 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. 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. 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. 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. In order for an SSL certificate to be trusted, that certificate must have been issued by a CA that is included in the trusted store of the device that is connecting.

Certificate Generation Capabilities in SMGR
Generating a PKCS#12 file including a signed certificate and private key directly from the SMGR UI. For Products with PKCS#12 keystore import functionality. Creating a signed certificate directly from the SMGR UI using a CSR. For Products generating the keys on their end and having the Certificate signed by the SMGR CA. Creating an end entity with Certificate Parameters 1 1 2 2 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 SMGR In 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. Clients (i.e., devices requiring a service) contact a server and are offered an identity certificate as proof of the server’s integrity. Clients verify the offered certificate by testing authenticity with a common trusted root CA certificate. If successfully authenticated; the client and server commence negotiations on an encryption scheme, and if successful, transmission is secured from that point. SMGR can act as a certificate authority similar to VeriSign and Symantec. Many adopters, such as CM, SM, and Presence, already use certificates issued by SMGR. 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. Export the SMGR CA. Add the Root Certificate of the System Manager to CM. Add SMGR Root Certificate to 96xx phones. Add the SMGR Root Certificate to any other SIP connections, such as CS1K and Radvision. Replace the SM SIP and HTTP Identity Certificates. Note: You must perform this step for all SM and Branch Session Manager Servers. 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 CSR Generate a Certificate Signing Request (CSR) and Private Key for SMGR Get the CSR signed by the CA Package the signed Identity Certificate and private key into a PKCS#12 format Install the third-party trusted Root certificate on SMGR Replace default SMGR Identity Certificate with the third-party signed identity certificate Generate a PKCS12 format keystore with the Identity certificate containing the values given in the end entity. Sign the given CSR and generate a PEM formatted certificate containing the values given in the end entity.

SMGR Root CA certificate
Root CA certificate can be downloaded from SMGR UI.

Session Manager Certificate Management
Session Manager and Branch Session Manager are identical in terms of certificate management. SM Certificate operation can be performed as a managed element through SMGR. 5 SM Software components (e.g.. SIP Link, HTTP_PPM) can use different Identity and Trusted Certificates. Each SM interface can support ONE Identity Certificate only. Certificates can be replaced with a SMGR internal signed CA Certificate or an imported third party PKCS#12 file. 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.

Session Manager TLS Layer Validation
SM applies the following validations for SIP TLS connections to other SIP Server Entities. Mutual TLS authentication: During a TLS handshake, mutual TLS authentication is performed. Additional validation of the SIP entity identity certificate: Further validation could be performed on the SIP entity Identity Certificate as per the Credential Name or the far-end IP address. If the credential name string is empty, the connection is accepted. If the credential name is configured, the credential name and the IP address of the SIP entity is searched in the following places in the identity certificate provided by the SIP entity. 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 Key Infrastructure) 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 by specifying 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® Trusted Hosts are allowed to assert identity in a P-Asserted-Identity header. TLS Layer validation Security Design in Avaya Aura® Session Manager Release Use of Cryptographyhttps://downloads.avaya.com/css/P8/documents/ Session Manager applies the following validations for SIP TLS connections: 1) Mutual TLS authentication: During the TLS handshake, the SIP entity and Session Manager validate each other certificate and perform mutual TLS authentication. 2) Additional validation of the SIP entity identity certificate: If mutual TLS authentication is successful, further validation is performed using the credential name or the far end IP address of the 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 the SIP entity is searched at following places in the identity certificate provided by the SIP entity. i. CN value from the subject ii. subjectAltName.dNSName iii. subjectAltName.uniformResourceIdentifier. For IP address comparison, the IP address string is converted to SIP:W.X.Y.Z before comparison. W.X.Y.Z is the remote socket IPV4 address. Also case insensitive search is performed in this case. 3) On the Session Manager Administration page, an administrator can enable or disable TLS endpoint certificate validation feature. CN value from the subject subjectAltName.dNSName subjectAltName.uniformResourceIdentifier XX1.example.com Signed by: SMGR root CA

Required Skills Based on Field Experience by ASAs

Recommendations Installing certificates can be complicated.
Plan for certificate migration upfront and do not wait until after install. Both the customer (or BP) and Avaya need to take responsibility upfront for identifying a certificate strategy. A lot of planning must be done to ensure that certificates are correctly installed. It is highly recommended to have an ASA involved before installation. APS has certificate expertise

SMGR Root CA certificate
Root CA certificate can be downloaded from SMGR UI.

Session Manager Certificate Management
Session Manager and Branch Session Manager are identical in terms of certificate management. SM Certificate operation can be performed as a managed element through SMGR. 5 SM Software components (e.g.. SIP Link, HTTP_PPM) can use different Identity and Trusted Certificates. Each SM interface can support ONE Identity Certificate only. Certificates can be replaced with a SMGR internal signed CA Certificate or an imported third party PKCS#12 file. 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.

Session Manager TLS Layer Validation
SM applies the following validations for SIP TLS connections to other SIP Server Entities. Mutual TLS authentication: During a TLS handshake, mutual TLS authentication is performed. Additional validation of the SIP entity identity certificate: Further validation could be performed on the SIP entity Identity Certificate as per the Credential Name or the far-end IP address. If the credential name string is empty, the connection is accepted. If the credential name is configured, the credential name and the IP address of the SIP entity is searched in the following places in the identity certificate provided by the SIP entity. 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 Key Infrastructure) 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 by specifying 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® Trusted Hosts are allowed to assert identity in a P-Asserted-Identity header. TLS Layer validation Security Design in Avaya Aura® Session Manager Release Use of Cryptographyhttps://downloads.avaya.com/css/P8/documents/ Session Manager applies the following validations for SIP TLS connections: 1) Mutual TLS authentication: During the TLS handshake, the SIP entity and Session Manager validate each other certificate and perform mutual TLS authentication. 2) Additional validation of the SIP entity identity certificate: If mutual TLS authentication is successful, further validation is performed using the credential name or the far end IP address of the 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 the SIP entity is searched at following places in the identity certificate provided by the SIP entity. i. CN value from the subject ii. subjectAltName.dNSName iii. subjectAltName.uniformResourceIdentifier. For IP address comparison, the IP address string is converted to SIP:W.X.Y.Z before comparison. W.X.Y.Z is the remote socket IPV4 address. Also case insensitive search is performed in this case. 3) On the Session Manager Administration page, an administrator can enable or disable TLS endpoint certificate validation feature. CN value from the subject subjectAltName.dNSName subjectAltName.uniformResourceIdentifier XX1.example.com Signed by: SMGR root CA

How to Renew expired SMGR/SM certificates
SMGR Certificate expired and admin not able to login to the web interface. System Manager Certificate were made valid for 2 years from the installation date. If you have upgraded your System Manager to a new major release since then the certificates will have been extended by 2 years at that time. 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 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 Manager PSN Session Manager SYSTEM MANAGER In 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 MANAGER Now 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.jks Run the following command and hit enter : echo | keytool -list -v -keystore sd1_external_keystore.jks 2>&1 | grep -m 1 Valid Check 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 Valid If all the certificates expiration dates are in the future, no immediate action is required If 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 minutes. From the System Manager Webpage under Home/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 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 Webpage The 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 PSN is applicable to all System Manager Installations which has not been upgraded for almost last two years and has expired or about to expire certificates. This PSN renews following: 1. Expired certificates of System Manager 2. 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 Session Manager uses several internal ID certificates to authenticate TLS connections within its internal components and with external entities (i.e. SIP TLS, Jboss mgmt, etc.). Some of these certificates expire within two years from the original installation date. This PSN describes the procedure to renew these certificates in the affected releases outlined above. PLEASE NOTE THAT FAILURE TO FOLLOW THE BELOW PROCESS COULD RESULT IN A COMPLETE SYSTEM OUTAGE SHOULD THE CERTIFICATES EXPIRE. Avaya strongly recommends upgrading all Session Manager and System Manager servers to release 6.3 to take advantage of several new features including enhanced alarming capabilities and automatic renewal of all Avaya certificates without the need for customer intervention. Resolution Please note that this PSN should be implemented only after you have completed the System Manager Certificate renewal procedure outlined in PSN u available on Avaya’s support site. SMGR Cert Renewal Utility SM Cert Renewal Process Product Support Notice: PSN003661u Product Support Notice: PSN003617u

Communication Manager Certificate Management
The Survivable Core and Survivable Remote servers Certificate administration is separately to the Main Server. Any certificate change on the Main Server (Duplex CM pair) will be automatically synchronized to the standby server. CM certificate scan be managed through the CM System Management Interface web pages CM uses up to five unique Identity Certificates for different Services/interfaces e.g. Session Manager, LDAP server. Each service/interface can only have ONE identity certificate. A single identity certificate and trusted certificate might be used for multiple CM services. Each CM service can have up to 8 trusted certificates. Download Trusted Certificates to CM Add Trusted Certificate to selected CM Services 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. There are 2 methods for CM to receive an Identity certificate. Generate CSR file and submit the CSR file to the CA. Upload and add the signed Certificate (PEM Format) to selected CM services. Upload PKCS12 format file and add selected CM Services.

Avaya Aura® Session Border Controller Certificates
Nomenclature Trusted Certificates are referred to as CA Certificates Identity Certificates are referred to as Certificates ASBCE certificates are managed through the SBC web Certificates administration page. install, view the information for a certificate, or delete a certificate from this page. CA Certificates and Certificates are displayed on this page. Can install multiple Trusted Certificates on the SBC and on remote applications required to establish TLS connections. The Avaya root CA certificate is installed by default. TLS connections can be established with other Avaya Aura® Unified Communications products or endpoints using the default certificates. If a customer requires the SBC to join an Enterprise PKI system, or if the SBC needs to communicate with third-party products securely, you must install the third-party Trusted Certificate on the SBC. Supports multiple Identity Certificates. All applications on the SBC that require secure connections (TLS) with peer entities can be configured to use one of the Identity Certificates for remote authentication. By default, the SBC uses the Avaya CA self-signed Identity Certificate that establishes TLS connections with other Avaya Aura® UC products or endpoints. If the customer requires the SBC to join the Enterprise PKI system, or if the SBC needs to connect to third-party products securely, you must install the third party Identity Certificate on the SBC. Use System Manager Root CA Internally with Public PKI CA Externally The 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.

ASBCE Certificates Continued

Which Certificates are required for Endpoints ?
Very Secure CA Signed by: Root Certificate XXXXXXX Signed by: X Identity Certificate SIP H.323 802.1X EAP-TLS Data Infrastructure Very Secure CA Signed by: Root Certificate Very Secure CA Signed by: HTTPS File Service (Utility Server) Software upgrades Utility Services does not support Third-party certificates Very Secure CA Signed by: Root Certificate Very Secure CA Signed by: Avaya Aura SM/PS HTTPS-PPM/TLS-SIP Trust Store with any Sub-CA certificates along with the root certificate, to validate the certificate chain right up to the root. TLS-XMPP Exchange Calendar TLS XXXXXXX Signed by: X Identity Certificate Very Secure CA Signed by: Root Certificate Avaya Aura SM HTTPS-PPM/TLS-SIP XXXXXXX Signed by: X Identity Certificate Very Secure CA Signed by: Root Certificate HTTPS-PPM/TLS-SIP SBC Avaya Aura SM

Which Certificates are required for Endpoints ?
Very Secure CA Signed by: Root Certificate XXXXXXX Signed by: X Identity Certificate H.323 VPN Phone VPN Gateway IPSec Very Secure CA Signed by: Root Certificate XXXXXXX Signed by: X Identity Certificate SSO for local Devices TLS Very Secure CA Signed by: Root Certificate Identity Certificate Optional - request and authenticate an identity certificate from the PC. Very Secure CA Signed by: Root Certificate H323 over TLS Communication Manager TLS Very Secure CA Signed by: Root Certificate XXXXXXX Signed by: X Identity Certificate Mutual authentication flag can be configured per station. H323 over TLS Communication Manager TLS

Trusted Certificates (Deskphones)
The Avaya Product Root CA and the Avaya SIP Root CA are default root certificates. If TRUSTCERTS is defined, any default trust relationship is removed. The default root certificates are included in the zip Software distribution package. Six (6) Root Certificates (PEM Format) can be loaded via the Trustcerts parameter into the trusted certificate repository. File Service (Utility Server) Trust Store XXXXXXX Identity Certificate If no certificate files are present in the trusted certificate repository (TRUSTCERTS parameter empty), any valid Identity certificate is accepted to establish a TLS connection. Allows to initially download certificate files through HTTPS. HTTP/HTTPs If the server presents an identity certificate that is issued by an intermediate CA, then any intermediate CA certificates along with the root certificate must be available in the trusted Certificate Repository

Troubleshooting for certificate download in 96x1 Set TRUSTCERTS
How to remove the loaded certificate from 96x1 phone. Reboot or reset of phone never remove certificate from phone TRUSTCERTS Only way to remove the certificate from phone TRUSTCERTS is by clearing the phone using craft procedure. No UI indication for administrator to confirm the certificate is properly downloaded in phone TRUSTCERTS. Only way is to see with a ethereal trace. Success scenario for 96x1 phone download certificate Failure case for download to TRUSTCERTS

SYS LOG Analysis for TRUSTCERTS
For certificate related logs, below are Log categories that need to be enable SECURITY  This is for certificate related issue HTTP  Down load of file from HTTP server ENCRYPT Encrypted related issue CALENDER Issue if cleaner integration fail SYS LOG SECURITY: +06: TEL | 0 ProcessCertificates: START\n - > This message show while phone start process to down load the certificate to TRUSTCERTS SECURITY: +06: TEL | 0 ProcessCertificates: Add CMT_STATE_TRUSTED_CERT\n - >Phone start to add certificate to its TRUSTCERTS directory. SECURITY: +06: TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Administrator has not set ##SET MYCERTURL in phone SECURITY: +06: TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Phone by pass SCEP URL SECURITY: +06: TEL | 0 ProcessCertificates - Unblock CMT_STATE_WAIT m_bMyCertWait=0.\n -- > Pone will not start wait process in order to download the certificate vi SCEP SECURITY: +06: TEL | 0 Process trusted certificate done\n Phone done process certificate. SECURITY: +06: TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n Phone store certificate onto TRUSTCERTS directory. As phone has 6 certificate phone will set all those in trusted directory SET TRUSTCERTS "AvayaITRoot2039.pem,smgr_ca.txt,av_sipca_pem_2027.txt,VerisignIntermediateCA.txt,VerisignRootCA.txt,default.cacert.pem,SMd efault.cacert.pem" SECURITY: +06: TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n ->Phone add all the certificate to the TRUSTCERTS SECURITY: +06: TEL | 0 ProcessCertificates: END\n Process certificate mechanism finished by phone.

Certificate Validation (Deskphones)
For HTTPS connection, the Identity Certificates Subject Alternative Name or the Common Name must match the FQDN or IP address of this connection For SIP-TLS connections, the Identity Certificates Subject Alternative Name (dnsName) or the Common Name must match the SIP Domain of the Set. Certificate Expiration date validation requires a valid source of time (SNTP) File Service (Utility Server) Trust Store XXXXXXX Identity Certificate HTTPS HTTPS/PPM Avaya Aura SM XXXXXXX Identity Certificate SIP/TLS The certificate validation mechanism TLSSRVRID provides increased security by allowing the client to validate the server’s identity and protect against man-in-the-middle attacks. Much like a person checking that the photo on a passport matches the appearance of the person carrying it.

Identity Certificates (Deskphones)
PKCS12 file Download using HTTP or HTTPS (H.323 R6.6) Trust Store SET TRUSTCERTS < CA root certificates Certificate renewal procedures will be automatically initiated according to % of a certificate's Validity interval Staging Area If 802.1x is enforced Certificate Authority SCEP/HTTP Simple Certificate Enrollment Protocol (SCEP) is an automated method to install and manage identity certificates. The terminals generate a private and public key pair locally and create a certificate signing request (CSR). SCEP is used to transmit the CSR with the public key to the CA. A successful response includes a signed identity certificate.

Troubleshooting for download of third party certificate on 96x1 Deskphone
Phone boot up process and requesting CA using SCEP for its own identity certificate. UI indication where third party certificate download fails.

SYS LOG analysis when no SCEP URL given in phone 46xx settings file
For certificate related logs, below are Log categories that need to be enable SECURITY  This is for certificate related issue HTTP  Down load of file from HTTP server ENCRYPT Encrypted related issue CALENDER Issue if cleaner integration fail SYS LOG SECURITY: +06: TEL | 0 ProcessCertificates: START\n - > This message show while phone start process to down load the certificate to TRUSTCERTS SECURITY: +06: TEL | 0 ProcessCertificates: Add CMT_STATE_TRUSTED_CERT\n - >Phone start to add certificate to its TRUSTCERTS directory. SECURITY: +06: TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Administrator has not set ##SET MYCERTURL in phone SECURITY: +06: TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Phone by pass SCEP URL SECURITY: +06: TEL | 0 ProcessCertificates - Unblock CMT_STATE_WAIT m_bMyCertWait=0.\n -- > Pone will not start wait process in order to download the certificate vi SCEP SECURITY: +06: TEL | 0 Process trusted certificate done\n Phone done process certificate. SECURITY: +06: TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n Phone store certificate onto TRUSTCERTS directory. As phone has 6 certificate phone will set all those in trusted directory SET TRUSTCERTS "AvayaITRoot2039.pem,smgr_ca.txt,av_sipca_pem_2027.txt,VerisignIntermediateCA.txt,VerisignRootCA.txt,default.cacert.pem,SMd efault.cacert.pem" SECURITY: +06: TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n ->Phone add all the certificate to the TRUSTCERTS SECURITY: +06: TEL | 0 ProcessCertificates: END\n Process certificate mechanism finished by phone.

Endpoint Authentication
Avaya Communicator Lync 6.4, One-X C and 96x1SIP support Endpoint Certificate validation MSFT CERTMGR XXXXXXX Signed by: X Identity Certificate Very Secure CA Signed by: Very Secure Root Certificate HTTPS ((PPM)/TLS (SIP)) Avaya Aura SM Mutual Authentication Enabled XXXXXXX Signed by: X Identity Certificate Very Secure CA Signed by: Very Secure Root Certificate HTTPS ((PPM)/TLS (SIP)) SBC Avaya Aura SM An Identity certificate may be configured to identify an Endpoint when requested by the server during the TLS handshake stage and the Server must have the corresponding trusted certificate to be able to verify the Endpoints Identity Certificate

TLS Mutual Authentication for SIP Devices Soft Mutual Authentication
In Aura FP4, even if endpoint certificate validation is turned on in Session Manager Administration, SM does not require that the endpoint provides a certificate. Current SM implementation is "soft" authentication, endpoint certificate is validated only if provided. When Mutual Authentication is enabled SM requests the SIP Endpoint to present its certificate. SM will validate the Certificate and allow the communication with that Endpoint to proceed only if the validation is successful. If the SIP Endpoint does not present a certificate, SM will let the communication to proceed.

TLS Mutual Authentication for SIP Devices Hard Mutual Authentication
Enforce “Hard” Mutual Authentication is being added in the SM FP1 (7.0.1) Release. Administrative capability is being added to strictly enforce SIP Endpoint certificate validation. If Endpoint TLS Certificate validation is set to “Required”, SM will not allow the communication with the SIP Endpoints to continue until the endpoints presents a valid certificates.

Support of H.323 signaling/registration over TLS
CM always request the certificate from the set. If “Mutual authentication” is “n” and the phone did not return certificate then TLS connection is established. If “Mutual authentication” is “n” and the phone did return certificate then the certificate is validated. If valid then connection is established, else TLS connection is closed. If “Mutual authentication” is “y” and the phone did not return certificate then TLS connection is established, but then CM will reject the connection using RRJ message. If “Mutual authentication” is “y” and the phone did return certificate then the certificate is validated. If valid then connection is established, else TLS connection is closed.

Endpoint Certificate Management without SCEP
XT Endpoints do not support SCEP. Certificate Signing Request (CSR) including transfer of the Signed Certificate and Trusted Certificate is manual process via the XT Endpoint Administration. The Avaya B179 Conference Phone does not support SCEP or a CSR capability. The Trusted Certificate, CA signed identity certificate and the private key needs to be extracted from the CA generated PKSC12 file and loaded separately via Web interface to the B179

How to rollout Certificates to UC Clients ?
The Certificate authority that issued your server certificates must be trusted by the client devices Action is required if servers are using certificates signed by a certificate authority that are not trusted by default in the device OS. In this scenario, the appropriate certificates must be distributed to the clients. Avaya Communicator and one-X Communicator will leverage the Windows trust store built into the OS to establish a secure TLS connection for communications through SIP, PPM, XMPP, HTTPS, LDAP. An end user leveraging the certificate import wizard or an administrator via Group Policy Objects for managed Pc´s can import a Trusted Certificate to the Windows certificate store under the “Trusted Root Certificate Authorities” folder. Use a Mobile Device Management solution to deploy the CA certificate to enrolled user devices CA certificate is available on an internal web page and users are directed to download the certificate to their devices. Send the CA certificate via to users and direct users to install the certificate on their devices Avaya Settings Text File “Trustcerts” Parameter. Available for AC Android. Future for iOS Communicator Client line.

How to Install Certificates Step 1 - Network Survey
Do a survey of all of the affected network elements and their interconnections. Focus on elements that face the clients and the external network: Avaya Aura Session Manager (including PPM) Avaya Session Border Controller for Enterprise Avaya Aura Conferencing (including web conferencing and document servers) Avaya Identity Engines (including Realm Mapper service) Avaya Client Enablement Services Avaya Multimedia Messaging Avaya Presence Server Utility Server Enterprise directory server You may also have additional third-party network elements participating in your network. Identify the interconnections between these elements and the rest of the network. As part of this survey, capture the software release number of each network element, including all of the clients and phone sets. In your network survey, make note of all certificates used. Many network elements will have more than one certificate, and each certificate may have slightly different characteristics depending on the type of service. See Certificate reference on page 9 for a detailed description of the required attributes for each type of certificate.

Step 2 - Site Evaluation Identify any elements of the network that need to be upgraded to support your new certificates. Some older versions of server software does not support replacing certificates. If you are using certificates of any length with SHA-2 digests, you should ensure you upgrade to a software release that supports SHA-2. Consult the product documentation for each of the elements in your network, including client applications and desk phones, to determine whether the installed software release supports the certificates you plan to install. It is important to note that you need to validate that both ends of each communication link support the certificates you plan to install. For example, if you install a SHA-2 identity certificate on the Avaya Aura Session Manager “Security Module SIP” service, then all of the network elements which connect directly to the Avaya Aura Session Manager (in the diagram above: Avaya Aura Communication Manager, Avaya Media Server, Avaya Messaging Server, Avaya Client Enablement Services, Avaya Aura Conferencing, Scopia, Avaya Presence Server, all SIP desk phones, and all SIP soft clients) must support SHA-2.

Step 3 - Deployment Deploy CA certificates throughout your network for the new certificate authority (CA) Ensure that the CA issuing your identity certificates is trusted throughout your network by installing the CA certificate into the trust stores on all of the network elements, including devices running client applications and desk phones. Instructions for updating the trust stores on each network element are detailed in the product documentation for each network element. If you use a well-known trusted third-party CA that is already supported by the devices running client applications, you will not need to deploy the CA certificate to these devices. However, you may still need to deploy the CA certificate to the servers and desk phones in your network. Note: Many network elements have multiple trust stores. Ensure that you install the new CA certificate(s) in all of the required trust stores. Deploy new server certificates Updates start at the “periphery” of the network and move towards the core elements. When planning your update, identify the network elements with the fewest incoming links and start there. On each server, install the new server identity certificate and verify that all connections to the server are functioning properly. Instructions for updating the server identity certificate on each network element are detailed in the product documentation for each network element. Note: Each server may have multiple service interfaces. Ensure that you install the appropriate new server certificates for each service interface. Remove support for the old CA certificate from your network Once you have validated that your updates are complete + all elements are using certificates from your new CA, you should remove trust for the old certificate authority. Instructions for updating the trust stores on each network element including the desk phones are detailed in the product documentation for each element. Caution: Do not remove support for the old CA certificate from your network until the new CA certificate has been successfully installed and tested. Removing the old CA certificate prematurely can result in service outages.

Certificate Reference
In general, certificates should comply with RFC 5280 and current NIST recommendations, including: Using a recommended key algorithm; Using a recommended key length; Using a recommended message digest algorithm to create the certificate signature. At time of writing, the current NIST recommendations were available at: There are several classes of certificates used within the Avaya Unified Communications solution portfolio: Web services (server) – used by the Avaya Realm Mapper, Avaya Aura Conferencing web conferencing and document server, Personal Profile Management (a service on the Avaya Aura Session Manager), Avaya Multimedia Messaging, and the Utility Server, as well as various management interfaces. SIP server – from a client perspective, the primary concern is the Avaya Aura Session Manager; however from a solution perspective many network elements have SIP connections to the Avaya Aura Session Manager. XMPP server – primarily between clients and the Avaya Aura Presence Server for instant messaging, however there are other elements which use XMPP to connect with the Avaya Aura Presence Server. LDAP server – while your enterprise LDAP server is not technically part of the Avaya Unified Communications solution, a number of clients and network elements are able to connect to your enterprise LDAP server for directory information. “Generic” – this catch-all category encapsulates the Avaya one-X Client Enablement Services Handset Server as well as many internal management interfaces within the solution.

Certificate Reference Continued
Most certificate vendors and the Avaya Aura System Manager interface provide a streamlined process for obtaining standard certificates. If you use this streamlined process, you must make sure of the following minimum requirements: The Subject Common Name field must include the fully-qualified DNS domain name of the server. The key algorithm and key size are compatible with your security policy The Subject Alternative Name field must have the following entries: ipAddress – must have the IP address of the server dNSName – must contain the fully-qualified DNS domain name of the server dNSName – if the certificate is used for a SIP service, it must contain a dNSName entry containing the SIP domain being used. If multiple SIP domains are in use, you must have one dNSName entry for each SIP domain. uniformResourceIdentifier – if the certificate is used for a SIP service, it must contain a uniformResourceIdentifier entry containing the SIP domain being used. If multiple SIP domains are in use, you must have one uniformResourceIdentifier entry for each SIP domain. Wildcards are not supported for SIP domain entries.

Example: Web service (server) certificates
Attribute Value Required? Subject CN={fqdn} required Validity validity period Authority Key Identifier hash required1 Subject Key Identifier recommended Subject Public Key Info public key algorithm public key data Signature signature algorithm signature value Key Usage digitalSignature optional2 nonRepudiation keyEncipherment dataEncipherment Extended Key Usage id-kp-serverAuth = id-kp-clientAuth = optional3 Subject Alternative Name IP:{ip} optional4 DNS:{fqdn} required5 Authority Information Access OCSP - URI: optional CRL Distribution Points URI: URI:ldap://{crl-server}{:crl-port}{/crl-dn} 1authority key identifiers are required elements in end entity certificates to establish a trust chain. 2 values may vary as specified in RFC 5280 and RFC required if the same identity certificate is used when the server is acting as a client. 4 for the 96xx endpoints, PPM is "always" defined as an IP address, so PPM certificates must contain the IP:{ip} Subject Alternative Name entry when these endpoints are part of the solution. 5 if the CN field of the Subject contains the fully-qualified domain name of the server, then the DNS:{fqdn} entry in the Subject Alternative Name is optional. Web service certificate references RFC 2818 (2000), HTTP Over TLS Special notes Wildcard name matching is defined in RFC 2818

CAs can certify other CAs or “end entities”
CA Hierarchies CAs can certify other CAs or “end entities” Certificates are links in a tree of EEs & CAs Root CA CA CA EE CA EE EE

Does Alice trust Bob’s Key?
Alice trusts Bob’s key if there is a chain of certificates from Bob’s key to a root CA that Alice implicitly trusts CA EE Root CA Root CA Root CA CA CA EE Febuary 21, 2006

Chain Building & Validation
“Given an end-entity certificate, does there exist a cryptographically valid chain of certificates linking it to a trusted root certificate?” CA EE Root CA Root CA Root CA CA CA EE

Chaining Certificates
In theory, building chains of certificates should be easy “Just link them together like dominos” In practice, it’s a lot more complicated...

Chain Building Details (1)
Root CA Root CA CA1 Root CA CA2 CA1 CA2 CA1 EE1 CA1 EE2 CA2 EE3 EE1 EE2 EE3

Root CA1 Root CA2 CA1 CA2 EE1 EE2 EE3 February 21, 206

CA2 CA1 EE1 Root EE2 EE3

Bridge CA CA2 CA1 EE1 Root EE2 EE3

Bridge CA CA2 CA1 EE1 Root EE2 EE3 Practical Aspects of Modern Cryptography February 21, 2006

Bridge CA CA2 CA1 EE1 Root EE2 EE3

The X.500 Directory Model The model SSL/TLS uses, the X.509 certificate model, is based on names Names as principles Specifically, X.509 is based on the X.500 directory model X.500 defined a global, all-encompassing directory, to be run by the telcos One directory to rule them all, one directory to define them...

State or Province SP = WA
X.500 Distinguished Names In the X.500 model, everything has a single, unique, global, assigned name There is a worldwide hierarchy, and you’re in it! Country C=US SP = OR State or Province SP = WA Locality L=Redmond Organization O=Microsoft L=Seattle O=Univ. of Washington SP = CA ebruary 21, 2006

DNs in Practice Name is unique within the scope of the CA’s name
Public CAs (e.g. Verisign) typically set C = CA Country O = CA Name OU = Certificate type/class CN = User name E= address

Private-label DNs If you own the CA, you get to decide what fields go in the DN Really varies on what the software supports Can get really strange as people try to guess values for fields that are required by software Software requires an OU, we don’t have OUs, so I better make something up!

DNs in X.509 Certificates The X.509 certificate standard began as a way to associate a certificate with a node in the directory. How is the subject of a cert identified? By its DN. How is the issuer of a cert identified? How are certificates linked together? By DNs.

Key fields in a certificate
The core fields of an X.509 certificate are The subject public key The subject Distinguished Name The issuer Distinguished Name What’s missing here? The issuer’s public key is not present in the certificate. You can’t verify the signature on the cert without finding a parent cert!

Back to Chain Building OK, assume we’re a “relying party application” -- something that received an end-entity certificate and wants to verify it. Our task is to build a cert chain from that end-entity cert to one of our trusted roots How do we do that? We start with our EE cert, and using the information contained within we look for possible parent certificates. Practical Aspects of Modern Cryptography February 21, 2006

Parent certs What’s a valid parent certificate?
In the raw X.509 model, parent-child relationships are determined solely by matching Issuer DN in the child to Subject DN in the parent Recall that there’s an assumption that you have a big directory handy to find certs. If you don’t have a directory handy, you need to do the matching yourself This is not as easy as you might think… Practical Aspects of Modern Cryptography February 21, 2006

Avaya Aura Security Certificates Demystified

Similar presentations

Presentation on theme: "Avaya Aura Security Certificates Demystified"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Avaya Aura Security Certificates Demystified

Similar presentations

Presentation on theme: "Avaya Aura Security Certificates Demystified"— Presentation transcript:

Similar presentations

About project

Feedback