Product Support Notice

Transcription

1 PSN # PSN005110u Product Support Notice 2017 Avaya Inc. All Rights Reserved. Original publication date: 8 Dec This is Issue #03, published date: 22 Dec Severity/risk level High Urgency Immediately Name of problem Expiration of AACC-provided AES test certificates on January 6, 2018, will result in loss of all services after a server restart on all Contact Center 6.2 or later releases and AES clients that have this default certificate in place. Products affected All Avaya Aura Contact Center 6.2 or later releases where the AES is using the default certificate provided by AACC for AE services link. Any clients using the AES service with this default certificate in place. Problem description Avaya Aura Contact Center provided, for test purposes only, an AES certificate to facilitate the configuration of the AES Services TLS connection for AE Services-based clients, of which AACC is one. If this certificate has not already been replaced with a unique certificate, then this must be done before the default certificate expires on January 6, Failure to replace the default certificate with a unique certificate will result in a Contact Center service outage after a service restart has been performed after January 6, The outage will not recover until the default certificate is replaced with a unique certificate. This AES certificate, which can be seen in the screen shot below, was intended for lab systems deployment only. If you have been using this certificate in a production environment, it is now a requirement that you prepare and execute a rollout plan, as soon as possible, to update the AE Services server with your own certificates. This impacts all versions of AACC deployments and any other AES clients in the deployment that utilize AE Services where the default AES certificate is applied on AES. Avaya states that these certificates should only be used in a test and lab environment and must be removed if used on live deployments and replaced with a unique certificate as per the AES documentation. Other non-aacc AE Services clients This PSN details the removal of the default certificate from the AES and specifically from the aesservice service. If the deployment has additional AE Services clients utilizing this aesservice, then these have to be taken into consideration. All clients of aesservice will have to be populated with the trusted root CA certificate. Consideration will have to be given to whether all clients can import this certificate and the process to do it before removing the certificate to avoid disruption of service.

2 Immediate Action Required Replacement of the AES server certificate shown above before service is lost. Please ensure that this default certificate is replaced by a unique server certificate. Workaround or alternative remediation Given below are the steps to remove and generate a new AACC server certificate. Please follow these steps carefully while also completing changes from PSN on the AE Services server while also referring to the official AE Services documentation for the AE Services release that you are currently on. In this example, it is AES and the section titled "Creating a server certificate request for AE Services" in the Avaya Aura Application Enablement Services Documentation Library 7.1.1, which can be found on support.avaya.com site. Also PSN Avaya Aura Application Enablement (AE) Services Server Certificate Change and Expiration Notification details alternative methods to replace default certificates at AES with unique certificates. Planning checkpoints before replacing the default certificate Evaluation of other AES clients using aesservice Before removing the certificate, establish the number of AES clients using aesservice and propagate the designated Certificate Authority (CA) trusted root certificate to the clients to ensure that, when the certificate is replaced on the AES, there is minimal disruption to the existing AES clients. By ensuring that the CA trusted root certificate is on all clients, when the service is resumed, the clients will have the appropriate certificates to trust the AES service and establish a secure connection. Please ensure that the process of adding this CA trusted certificate is known and that all clients have the capability to import a certificate. Timescale in receiving the unique server certificate Please take into account the purchase authorization process of your organization and incorporate the time it will take in determining when the new certificate will be available to be applied to your system. Extended Key Usage value and Certificate Authority When choosing your designated Certificate Authority (CA), please perform due diligence to determine from the provider whether the signing of the certificate involves the populating of the Extended Key Usage (EKU) property. If the CA populates the EKU, then there is a requirement that the EKU must have both Client and Server Authentication or none at all. The CA provider should be able to provide that information before removing the certificate. So it must be either a) or b) a) No value at all in the EKU Or b) Client Authentication and Server Authentication in the EKU. Multiple customer options to create the new server certificates: Use your own PKI Use Avaya Aura s System Manager (SMGR) Trust Management PKI feature Use a third party vendor Use OpenSSL to create your own Certificate Authority (CA)

3 Generating the Certificate Signing Request (CSR) for AES The first step in creating a unique certificate is the generation of the Certificate Signing Request (CSR). This CSR is sent away to the designated Certificate Authority (CA) to be signed. The CA will issue and return the unique certificate and the associated trusted CA Root certificate. At AES, the CSR can be generated when the existing default certificate is in place and without disturbing existing AE Services. Generating a Certificate Signing Request (CSR) In AES, navigate to Security > Certificate Management > Server Certificates. Click Add, and enter appropriate information in each field as required. In Certificate Alias, choose "aesservices". Provide information based on your specific needs. Note that the encryption algorithm of SHA256 and key length of 2048 should be the minimum selected for a secure connection. Click Apply. The system displays the following CSR data, which you must provide to your CA to be signed.

4 Next step Remove existing and add new Root CA and AES Identity certificates to AES. Adding the new Root CA certificate to AES Import the new CA certificate into the AE Services server after retrieving the new CA certificate: 1. Using the AE Services Management Console, navigate to Security > Certificate Management > Trusted Certificates. 2. Click on the Import button, and upload the CA certificate retrieved from the CA. Give it an alias name (example: cacert). 3. Click the Apply button. Note: You must import the CA certificate before you can import the AE Services identity certificate in the next steps. Removal of the default identity certificate for AES Remove the default AES identity certificate after retrieving the new custom identity certificate: 1. Using the AE Services Management Console, navigate to Security > Certificate Management > Server Certificates. 2. Click Security > Certificate Management > Server Certificates. 3. (Optional) As the default aesservices certificate is about to expire, select it and click Delete.

5 Adding the new custom identity certificate to AES You can add the new certificate in one of the following ways: Manual enrolment: Import the signed CSR and the signed Identity certificate from the location where you placed them. Auto enrolment: Select Auto Enroll if you use SCEP certificates. In this example, the manual option is being used. 1. To see the generated request, go to Security > Certificate Management > Server Certificates > Pending Request. 2. Select the Manual Enroll option. 3. Follow the steps to select the new Identity certificate and import the new identity certificate into AES. Note that a restart at AES will cause a loss of service. 4. Restart AES. 5. Check that the new Server certificate has been added sucessfully by going to Certificate Management Server Certificates. The new server certificate should be listed like the example shown below. Review AACC; if the certificates in the AACC security store are custom certificates, then AACC must be configured to work with the replacement AES and Root CA certificates. Complete the task by following the section titled Add custom Root CA certificate to the AACC certificate store

6 Review AACC; if the certificates in the AACC security store are the out of box default certificates, they must be replaced with custom certificates. Do so by following the section titled Creating custom identity certificate for AACC Add custom Root CA certificate to the AACC certificate store The same Certificate Authority (CA) root certificate used to sign the AES CSR should also be imported into the AACC security store to allow AACC to establish trust with the new AES signed certificate. Retrieve the Root CA certificate and place the certificates on the AACC server in any temp folder. 1. Launch Security Manager / Certificate Manager and log in using the store password. 2. In the Add Certificate tab, add the new CA Certificate as follows: a. Select Add Certificate Automatically. b. Browse to the temp folder where the new Root CA certificate is saved. c. Select the new Root CA certificate. d. Add the new Root CA certificate to the store. e. Select the Display Certificates tab and view the Root CA certificate. Creating custom identity certificate for AACC The first step in creating a custom certificate is the generation of what is called the Certificate Signing Request (CSR). To replace the existing certificate at AACC requires deletion of the existing store, then creation of new certificate store produces a new CSR. This CSR is sent away to the designated Certificate Authority (CA) to be signed and from that you will receive a new custom certificate and an associated trusted CA certificate. At AACC 6.x and 7.x, the CSR steps cannot be completed without stopping services. Generating the Certificate Signing Request (CSR) for AACC 6.x & 7.x 1. Using SCMU, stop AACC services. 2. Launch Security Manager / Certificate Manager and log in using your store password. 3. (Optional) On release 7.x, back up the current store using the Store Maintenance tab. a. Browse to a suitable backup location and click the Backup button. 4. On the Store tab, delete the current store if it is the test default AACC store provided at installation: a. Click the Security Store tab, and then click the Delete Store button. b. Exit Certificate Manager. 5. Re-launch Security Manager / Certificate Manager (no store means no store password exists yet). The system clears the store and displays the new screen to fill in information for generation of the new store. Mandatory required information is indicated by a red asterisk. All other information is optional but should be provided for completeness and to allow your organisation to fill in bespoke information relevant to the customer. 6. Provide information in the following fields, which are prepopulated, but these fields can be modified prior to the store being created: FQDN (or also known as the CN value). Encryption Algorithm Level. The default level is SHA256. Key Size. The default is Subject Alternative Name (SAN) fields o On AACC 7.x: Select DNS for SAN Type, and populate SAN Value with the Managed FQDN. o On AACC 6.x: There is no option for SAN Type and Value, so those items are omitted. Note: When a client browser connects to CCMA over an https connection, the https connection will typically specify the CCMA Managed FQDN. When SAN is omitted, the CCMA will identify itself by using local FQDN instead of Managed FQDN and the browser will present a warning to that effect. The warning has no impact to correct the function of the CCMA session. Elimination of that warning is outside the scope of this document. 7. After you fill in the necessary information and pick a password, click the Create Store button to create the store.

7 This operation has several implications: It creates an underlying security store Java Key Store (JKS) on the server. The JKS store is now encoded with the levels selected when the store was created and cannot be changed. A Certificate Signing Request (CSR) is automatically created and displayed on the user interface. Do one of the following: Copy the CSR directly from the screen, paste it into an , and send for signing to your designated CA. Highlight the text and Ctrl+C to copy directly from user interface. Copy the physical copy of the CSR, created automatically from the server, and send to be signed. The location is displayed on the user interface. The CSR file remains on the server unless deleted manually from the location or if the store is deleted. On AACC 7.x, an automatic backup of the store, the encoded password, and the CSR file are made and displayed to the user after the store has been created.

8 Process the AACC CSR using System Manager Trust Management If using other CA to process CSR, skip ahead to the section titled Add the Root CA and AACC Signed Identity certificates to AACC. When using SMGR as CA, process the CSR using System Manager Trust Management. At SMGR, create an "End Entity" for the AACC server: 1. Using the SMGR web console, navigate to Security (under Services) > Certificates > Authority > Add End Entity (under RA Functions). 2. In the End Entity Profile field, click INBOUND_OUTBOUND_TLS. 3. Type username equal to the AACC name (friendly/alias name for the AACC). 4. Type password (Enrollment Code). Retain password for use during CSR enrollment (below). 5. Confirm the same password (Enrollment Code). 6. Complete the fields that you want in your certificate: Mandatory required information is indicated by a tick mark under the required column. All other information is optional but should be provided for completeness and to allow your organisation to fill in bespoke information relevant to customer. a. CN, Common name. Example aacchost.yourcompany.com b. C, Country: US 7. In Certificate Profile, select ID_CLIENT_SERVER. 8. In the CA drop-down menu, click tmdefaultca. 9. In the Token drop-down menu, click User Generated. 10. Click the Add button. Note: On the top of the page, the system displays the message End Entity <username> added successfully. Next step Add the new Root CA and AACC Signed Identity certificates to the AACC security store.

9 Add the Root CA and AACC Signed Identity certificates to AACC Retrieve the Root CA certificate and the AACC Identity certificate from SMGR (or from other preferred CA) and place both certificates on the AACC server in any temp folder. 1. Launch Security Manager / Certificate Manager and log in using your new store password. 2. In the Add Certificate tab, add the new CA Certificate as follows: a. Select Add Certificate Automatically. b. Browse to the temp folder where new Root CA certificate is saved. c. Select the new Root CA. d. Add the new Root CA to the store. 3. In the Add Certificate tab, add the new signed AACC identity certificate as follows: a. Select Add Certificate Automatically. b. Browse to the temp folder where new signed AACC certificate is saved. c. Select the new signed AACC certificate. d. Add the new signed AACC certificate to the store. The system displays a message indicating the success or failure of the imports. 4. Select the Display Certificates tab and view the new certificates information.

10 If the AES unique certificates are signed by another CA, then you must add their Root CA certificate into the store to allow AACC to trust any certificates coming from AES during secure negotiation. See Add custom Root CA certificate to the AACC certificate store. 5. Restart AACC services to pick up the new changes to the store. Additional Checks on AES once AACC unique Certificate is in place By changing the certificate on AACC store, you must ensure that AES is aware of this certificate and the following are standard checks when changing the AACC certificate. The checks are mentioned in this PSN as important checkpoints before attempting to reestablish a secure connection between AES and AACC. All of the information below can be found on the AES and AACC documentation for the relevant release you are on. Configuring AES to communicate with AACC - Checkpoint 1 - Trusted Host Entry Any client that wishes to connect to AES must have an entry in the Host AA - Trusted Hosts table. For AACC, the full machine FQDN (CN) value must be entered into this field, and that must match exactly with the corresponding entry displayed on Security Manager. The FQDN should be typed in lowercase because the entry is casesensitive. The other attributes of the entry can be seen in the screen shot below Service Type: TR87 User Authentication Policy: AUTHENTICATION_NOT_REQUIRED User Authorization Policy: UNRESTRICTED_ACCESS Security Manager Full Computer Name (FQDN) field and AES s Certificate CN or SubAltName must match

11 Configuring AES to communicate with AACC - Checkpoint 2 - CA Trusted Certificates Since the certificate has been changed on AACC and perhaps using a different Certificate Authority (CA) than what was used before then, that CA s trusted root certificate needs to be placed into the CA Trusted Certificates table so AES can trust the certificate from AACC when it is sent over. 1. In AES, select Security > Certificate Management > CA Trusted Certificates. 2. Place the Certificate Authority (CA) root certificate that has signed the AACC Identity certificate. 3. Click the Import option on the page. 4. Browse to where you have previously saved the CA root certificate. 5. Give it an alias title that makes sense and can be used to identify later on and to its purpose. 6. Click Apply to add the root certificate to the store once selected. 7. Once all of the above has been checked and changed, restart AACC services and check the SIP-CTI connection using the SGM Management client. Remarks Patch Notes The information in this section concerns the patch, if any, recommended in the Resolution above. Backup before applying the patch

12 Download Patch install instructions Verification Failure Patch uninstall instructions Service-interrupting? Yes Security Notes The information in this section concerns the security risk, if any, represented by the topic of this PSN. Security risks There are no security risks as the link will become inoperable once a secure connection cannot be made. Avaya Security Vulnerability Classification Mitigation If you require further information or assistance please contact your Authorized Service Provider, or visit support.avaya.com. There you can access more product information, chat with an Agent, or open an online Service Request. Support is provided per your warranty or service contract terms unless otherwise specified in the Avaya support Terms of Use. Disclaimer: ALL INFORMATION IS BELIEVED TO BE CORRECT AT THE TIME OF PUBLICATION AND IS PROVIDED "AS IS". AVAYA INC., ON BEHALF OF ITSELF AND ITS SUBSIDIARIES AND AFFILIATES (HEREINAFTER COLLECTIVELY REFERRED TO AS "AVAYA"), DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND FURTHERMORE, AVAYA MAKES NO REPRESENTATIONS OR WARRANTIES THAT THE STEPS RECOMMENDED WILL ELIMINATE SECURITY OR VIRUS THREATS TO CUSTOMERS SYSTEMS. IN NO EVENT SHALL AVAYA BE LIABLE FOR ANY DAMAGES WHATSOEVER ARISING OUT OF OR IN CONNECTION WITH THE INFORMATION OR RECOMMENDED ACTIONS PROVIDED HEREIN, INCLUDING DIRECT, INDIRECT, CONSEQUENTIAL DAMAGES, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF AVAYA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE INFORMATION PROVIDED HERE DOES NOT AFFECT THE SUPPORT AGREEMENTS IN PLACE FOR AVAYA PRODUCTS. SUPPORT FOR AVAYA PRODUCTS CONTINUES TO BE EXECUTED AS PER EXISTING AGREEMENTS WITH AVAYA. All trademarks identified by or TM are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners.