Avaya Aura Contact Center and Avaya Contact Center Select Custom Certificate, Single Sign-On Configuration and Troubleshooting Guide

Transcription

1 Avaya Aura Contact Center and Avaya Contact Center Select Custom Certificate, Single Sign-On Configuration and Troubleshooting Guide Release 7.x July 2018 ver

2 2017 Avaya Inc. All Rights Reserved. Notice While reasonable efforts have been made to ensure that the information in this document is complete and accurate at the time of printing, Avaya assumes no liability for any errors. Avaya reserves the right to make changes and corrections to the information in this document without the obligation to notify any person or organization of such changes. Documentation disclaimer Documentation means information published by Avaya in varying mediums which may include product information, operating instructions and performance specifications that Avaya generally makes available to users of its products. Documentation does not include marketing materials. Avaya shall not be responsible for any modifications, additions, or deletions to the original published version of documentation unless such modifications, additions, or deletions were performed by Avaya. End User agrees to indemnify and hold harmless Avaya, Avaya's agents, servants and employees against all claims, lawsuits, demands and judgments arising out of, or in connection with, subsequent modifications, additions or deletions to this documentation, to the extent made by End User. Link Disclaimer Avaya is not responsible for the contents or reliability of any linked Web sites referenced within this site or documentation provided by Avaya. Avaya is not responsible for the accuracy of any information, statement or content provided on these sites and does not necessarily endorse the products, services, or information described or offered within them. Avaya does not guarantee that these links will work all the time and has no control over the availability of the linked pages. Warranty Avaya provides a limited warranty on its Hardware and Software ( Product(s) ). Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya s standard warranty language, as well as information regarding support for this Product while under warranty is available to Avaya customers and other parties through the Avaya Support Website: Please note that if you acquired the Product(s) from an authorized Avaya reseller outside of the United States and Canada, the warranty is provided to you by said Avaya reseller and not by Avaya. Licenses THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA WEBSITE, ARE APPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/OR INSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC., ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER (AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITH AVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESS OTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOES NOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINED FROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR AN AVAYA AUTHORIZED RESELLER; AVAYA RESERVES THE RIGHT TO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSE USING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BY INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF YOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING, DOWNLOADING OR USING THE SOFTWARE (HEREINAFTER REFERRED TO INTERCHANGEABLY AS YOU AND END USER ), AGREE TO THESE TERMS AND CONDITIONS AND CREATE A BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THE APPLICABLE AVAYA AFFILIATE ( AVAYA ). Avaya grants End User a license within the scope of the license types described below. The applicable number of licenses and units of capacity for which the license is granted will be one (1) unless a different number of licenses or units of capacity is specified in the Documentation or other 2 P a g e

3 materials available to End User. Designated Processor means a single stand-alone computing device. Server means a Designated Processor that hosts a software application to be accessed by multiple users. Software means the computer programs in object code, originally licensed by Avaya and ultimately utilized by End User, whether as stand-alone Products or pre-installed on Hardware. Hardware means the standard hardware originally sold by Avaya and ultimately utilized by End User. Concurrent User License Concurrent User License (CU). End User may install and use the Software on multiple Designated Processors or one or more Servers, so long as only the licensed number of Units are accessing and using the Software at any given time. A Unit means the unit on which Avaya, at its sole discretion, bases the pricing of its licenses and can be, without limitation, an agent, port or user, an or voice mail account in the name of a person or corporate function (e.g., webmaster or helpdesk), or a directory entry in the administrative database utilized by the Software that permits one user to interface with the Software. Units may be linked to a specific, identified Server. Copyright Except where expressly stated otherwise, no use should be made of materials on this site, the Documentation, Software, or Hardware provided by Avaya. All content on this site, the documentation and the Product provided by Avaya including the selection, arrangement and design of the content is owned either by Avaya or its licensors and is protected by copyright and other intellectual property laws including the sui generis rights relating to the protection of databases. You may not modify, copy, reproduce, republish, upload, post, transmit or distribute in any way any content, in whole or in part, including any code and software unless expressly authorized by Avaya. Unauthorized reproduction, transmission, dissemination, storage, and or use without the express written consent of Avaya can be a criminal, as well as a civil offense under the applicable law. Third-party components Certain software programs or portions thereof included in the Product may contain software distributed under third-party agreements ( Third Party Components ), which may contain terms that expand or limit rights to use certain portions of the Product ( Third Party Terms ). Information regarding distributed Linux OS source code (for those Products that have distributed the Linux OS source code), and identifying the copyright holders of the Third-Party Components and the Third-Party Terms that apply to them is available on the Avaya Support Website: Preventing Toll Fraud Toll fraud is the unauthorized use of your telecommunications system by an unauthorized party (for example, a person who is not a corporate employee, agent, subcontractor, or is not working on your company's behalf). Be aware that there can be a risk of Toll Fraud associated with your system and that, if Toll Fraud occurs, it can result in substantial additional charges for your telecommunications services. Avaya Toll Fraud Intervention If you suspect that you are being victimized by Toll Fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at for the United States and Canada. For additional support telephone numbers, see the Avaya Support Website: Suspected security vulnerabilities with Avaya products should be reported to Avaya by sending mail to: securityalerts@avaya.com. Trademarks Avaya, Avaya Aura, Avaya, and Avaya Aura are registered trademarks of Avaya Inc. in the United States of America and/or other jurisdictions. 3 P a g e

4 All non-avaya trademarks are the property of their respective owners. Downloading Documentation For the most current versions of Documentation, see the Avaya Support Website: Hardware Support For full hardware support, please see Avaya Support Notices for Hardware Documentation, document number on the Avaya Support Web site, Contact Avaya Support Avaya provides a telephone number for you to use to report problems or to ask questions about your Product. The support telephone number is in the United States. For additional support telephone numbers, see the Avaya Web site: 4 P a g e

5 Table of Contents 1. Introduction Scope Disclaimer How TLS and Certificate are used Examples of Protocol Handshake TLS Protocol Handshake Server Side Client Side MTLS Protocol Handshake Certificate and the Certificate Authority (CA) Basic anatomy of a digital Certificate Common Definitions to Understand Certificate Authority Subordinate CA (Certificate Authority) Certificates Root or Trusted Certificate Identity Certificate Summary of Typical Certificate Hierarchies for an Avaya Aura Solution Certificate Format Encoding Types Formats Personal Information Exchange (PKCS #12) Cryptographic Message Syntax Standard (PKCS #7) DER-encoded binary X Base64-encoded X PEM-encoded X Creating Custom Certificates for AACC / ACCS Chained Certificates (PKCS #7) Support Launching Security Manager P a g e

6 10.3 Security Store Tab (shown on initial launch) Security Store Tab (Example information filled in before creating store) Certificate Request Tab (After store creation) What does that mean? Security Template Requirement Template requirements Signing the CA Getting your signed security certificate Getting your root CA security certificate Importing Certificates to AACC/ACCS Important Information on the Store Configuring AES to Communicate with AACC Checking AACC AES SIP-CTI link Troubleshooting AACC AES SIP-CTI link Setting the security levels for the Contact Center Example of security setting changes What else is configured automatically What's not covered by the store CCT OI and CCMS TLS Configuration CCT OI Enable TLS Generate CSR Use CSR Import CA Certificate After Importing CA cert Import Signed Cert TLS Fully Configured Resetting TLS configuration CCMS OI TLS configuration CCMS OI before TLS configuration CCMS OI after TLS configuration CCT OI and CCMS OI High availability considerations ACC 7.X SSO Setup with System Manager 7.X P a g e

7 7 P a g e

8 1. Introduction Avaya Aura Contact Center (AACC) and Avaya Contact Center Select (ACCS) incorporate in its deployment a means to secure transmissions using Transport Layer Security (TLS). Like most secure systems it requires some additional configuration over a non-secure deployment and as such a certain amount of knowledge of the concepts of security and security certificates which are used to secure the connections that the solution utilizes. This document will cover the main points of TLS and Security certificates from a conceptual point of view first before diving into the specifics of how to secure the solution. 8 P a g e

9 2. Scope As with every solution, there are many elements of it which are bespoke to it, this document is focused on providing a walkthrough of how one can secure communications. Elements of the document must choose a specific deployment and get the core message across on how to generate, sign and secure AACC and ACCS solutions. It cannot cover all deployment options. So, with that in mind, the document was written for a co-resident AACC solution and using a Windows 2012 R2 Certificate Authority (CA). Other deployments should be able to use this document as a guideline on how to secure communications with some minor differences (SANs for HA deployments) or additional duplicate configuration (Multimedia on a separate server) as typical examples of where this document will not cover in detail but should be enough to help you complete the task of securing the solution whatever type it is. 9 P a g e

10 3. Disclaimer Avaya has used reasonable commercial efforts to ensure that the information provided hereunder is accurate at the date of publication. Avaya may change any underlying processes, architecture, product, description or any other information described or contained in this document. Avaya disclaims any intention or obligation to update or revise the book, whether as a result of new information, future events or otherwise. This document is provided as is, and Avaya does not provide any warranty of any kind, express or implied. 10 P a g e

11 4. How TLS and Certificate are used TLS encryption is used for secure connections across control links o AACC/ACCS offers the ability to create TLS connection for: SIP signalling to SIP endpoints SIP signalling over SIP trunks to CM and other server products HTTPS web sessions TLS is a client-to-server protocol o Exchanges crypto list and version o Exchanges Identity certificates for validation (where ID certs have Name fields, Validation to/from dates, a digital signature by the signing CA) Avaya s approach for certificate management is to: o Offer new Product Identity certificates and Trusted CA certificates with enhanced signatures (SHA2 hashing and key length) o Recommend that demo Identity certificates no longer be deployed. 11 P a g e

12 5. Examples of Protocol Handshake 5.1 TLS Protocol Handshake This is typically the most commonly used form of TLS where the server requires the Identity certificate and root Certificate Authority certificate and client require the root Certificate Authority root certificate only Server Side So, this requires configuration on the server primarily (generating a certificate signing request (CSR) to be signed by a CA and then importing in the signed Identity certificate and root CA certificate) Client Side The client needs no real configuration, all is required is the root certificate of the CA that signed the Identity certificate on the server. Most client platforms have commercial CA root certificates already in place, installed by the underlying Operating System (OS) so if the customer picks a well-known commercial CA then the client needs no configuration at all. If not, then the root CA certificate must be placed on the client machine via some method (Group policy or other means). 12 P a g e

13 - Protocol Level MTLS Protocol Handshake Like TLS, MTLS has the same flow except in this case both ends can be deemed servers. In this case whoever instigates a connection is a client and the other is the server. So, with that in mind, you can duplicate the configuration aspect, where both ends need an identity certificate and respective root certificates (if signed by separate CA s unlikely scenario). An example in AACC where MTLS is used is the mandatory secure connection between AACC and AES. So, one would have to configure AACC and then AES to be able to communicate over a secure channel. 13 P a g e

14 14 P a g e

15 6. Certificate and the Certificate Authority (CA) A digital certificate is an electronic "passport" that allows a person, computer or organization to exchange information securely over the Internet using the public key infrastructure (PKI). A digital certificate may also be referred to as a public key certificate Just like a passport, a digital certificate provides identifying information, can be verified because it was issued by an official, trusted agency (Certificate Authority - CA) The certificate contains the name of the certificate holder (CN) Information about the organization that the certificate is issued to. A serial number. The validity period for the certificate. The allowed uses (client authentication, server authentication) A copy of the certificate holder's public key (used for encrypting messages and digital signatures). The digital signature of the certificate-issuing authority (CA) so that a recipient can verify that the certificate is real. To provide evidence that a certificate is genuine and valid, it is digitally signed by a root certificate belonging to a trusted certificate authority. Operating systems and browsers maintain lists of trusted CA root certificates so they can easily verify certificates that the CAs have issued and signed. When PKI is deployed internally, digital certificates can be self-signed 15 P a g e

16 6.1 Basic anatomy of a digital Certificate 16 P a g e

17 7. Common Definitions to Understand 7.1 Certificate Authority A certificate authority (CA) is a trusted entity that issues electronic documents that verify a digital entity's identity on the Internet. The electronic documents, which are called digital certificates, are an essential part of secure communication and play an important part in the public key infrastructure (PKI). 7.2 Subordinate CA (Certificate Authority) A Subordinate CA is a certificate authority (CA) that is at a level beneath the root CA. 7.3 Certificates A digital certificate provides authenticity to a user s or clients identity. A digital certificate contains several details relating to the client such as address, DN, address etc. Each digital certificate is issued (and signed) by a CA (Certificate Authority) and is only valid for a specific period Root or Trusted Certificate A root or trusted certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI) Identity Certificate The digital equivalent of an ID card used in conjunction with a public key encryption system. Also called a "digital ID," "digital identity certificate," "identity certificate" and "public key certificate 17 P a g e

18 8. Summary of Typical Certificate Hierarchies for an Avaya Aura Solution A simple PKI hierarchy may have no intermediate CA and only a Root CA Chain of Trust - A more evolved PKI model will have one or more intermediate CA s that point to a Root CA. The term Chain of Trust is used to describe the trust relationship between identities when using Subordinate (intermediate) CA`s Each End-Entity typically has a unique Identity Certificate and a copy of the Root or Intermediate Trust CA Certificate Chain 18 P a g e

19 9. Certificate Format Security certificates come in several different formats. The first four are supported by Windows OS, the last is not readily supported by applications on Windows but AACC/ACCS Security manager can handle import and export of this format since other servers in the solution require PEM. 9.1 Encoding Types There are two main types of encoding of certificates Binary encoding of a certificate with extensions of.crt or.cer. PEM is a Base64 encoding of a certificate represented in ASCII therefore readable as text. 9.2 Formats Personal Information Exchange (PKCS #12) The Personal Information Exchange format (PFX, also called PKCS #12) supports secure storage of certificates, private keys, and all certificates in a certification path. The PKCS #12 formats are the only file format that can be used to export a certificate and its private key Cryptographic Message Syntax Standard (PKCS #7) The PKCS #7 format supports storage of certificates and all certificates in the certification path. E.g. Chained certificates DER-encoded binary X.509 The Distinguished Encoding Rules (DER) format supports storage of a single certificate. This format does not support storage of the private key or certification path Base64-encoded X.509 The Base64 format supports storage of a single certificate. This format does not support storage of the private key or certification path PEM-encoded X.509 The standard format for OpenSSL and many other SSL tools. This format is designed to be safe for inclusion in ASCII or even rich-text documents, such as s. PEM certificates are frequently used for web servers as they can easily be translated into readable data using a simple text editor 19 P a g e

20 10. Creating Custom Certificates for AACC / ACCS Since 6.4 release AACC and ACCS have the ability for the user to be able to create custom security certificates. This is facilitated by the Certificate Manager application (Now known as Security Manager in 7.0.2) In the release there have been changes where the Out of The Box (OTB) certificates and store is no longer provided and so the customer must create custom certificates otherwise the system will, in the AACC case, unsecure and the SIP-CTI link will not be operational as it requires TLS, in the ACCS case prior to 7.0.2, similar in that the solution would be unsecure and the TAPID link would not be operational as it requires TLS. In only ACCS has the ability to communicate over TCP to IPO with some configuration on IPO and ACCS Chained Certificates (PKCS #7) Support As of 7.0.3, Certificate Manager/Security Manager can import in chained certificates (PKCS #7). Prior to the customer must extract the individual certificates out of the certificate and import each one in individually Launching Security Manager Security Manager can be found in the shortcuts and tiles on Windows 2012 R2 systems 20 P a g e

21 The following are the assumptions: o o o o o There is no existing AACC/ACCS security store. Once launched, and there was no existing store, the user interface will display the main tab showing the details required to be entered in. Any piece of information that is mandatory is indicated by a red asterisk. All other information is not required to be filled in to create a store but for completeness and to allow your organisation to fill in bespoke information relevant to their standards. There are some fields filled in automatically: The FQDN (or also known as the CN value). This can be modified. Encryption Algorithm Level. The default level is SHA256. This can be modified Key Size. The default is This can be modified The Subject Alternative Name (SAN) fields can be populated with your specific requirements. Note that once the store is created SANs cannot be modified Overall once the store has been created all the fields on this tab cannot be modified apart from the password. 21 P a g e

22 10.3 Security Store Tab (shown on initial launch) 22 P a g e

23 10.4 Security Store Tab (Example information filled in before creating store) 23 P a g e

24 10.5 Certificate Request Tab (After store creation) Now that the store has been created, the next step is getting the Certificate Signing Request (CSR) signed by the designated Certificate Authority (CA) What does that mean? Now you have created a store and a CSR but this is of no use as the CSR can be seen as in an intermediate step, it needs a CA to put its stamp on it for it to become a security Identity certificate that can be used to secure services. 24 P a g e

25 The following steps show how to sign a CSR if you have your own private CA. By adding a Certificate Authority role to a domain controller will create a CA in your network. By creating a CA rather than use a commercial 3 rd party has some benefits such as issuing security certificates when you wish and at no additional cost. Disadvantages of using your own CA is that this CA will not be recognised outside your network and the root CA certificates that are required for clients to connect securing to the server will have to be distributed manually by yourself. Picking a 3 rd party CA avoids the last point as most commercial CA s have their root CA certificate in most client s operating systems. So, this example is a private CA and the steps to signing a CSR. If you pick a commercial 3rd party CA then these steps are not required as the designed CA will perform these operations for you. 25 P a g e

26 11. Security Template Requirement 11.1 Template requirements AACC and AES communicate over MTLS only. So, for a Certificate Authority to sign the CSR generated by AACC it needs to use a specific type of template. Most standard CAs issue Identity certificates as client authentication only or server authentication only but not both. If you use your own private or company CA then a custom template will have to be created if one does not exist that has both Client and Server Authentication. By selecting an existing template on the CA, say Web for example and then making a copy of it and expanding it to include Server authentication (Web has client authentication already) you can create the security template required for AACC and AES MTLS requirement. 26 P a g e

27 12. Signing the CA Copy or the CSR to the location of your CA. This example is using the Web interface to sign the certificate; it can also be done through the certificate authority applications on the server. Select the Request a certificate option advanced certificate request Submit a certificate request. 27 P a g e

28 Paste in the CSR text and select the Certificate Template drop list and select the custom-made Client- Server Authentication Template and then hit Submit to sign the CSR 28 P a g e

29 13. Getting your signed security certificate Your CA has now signed the CA, the next step is to download the Identity Certificate (Signed) and the CA root certificate so they can be imported back into the security store on AACC/ACCS. Default encoded option is fine, both are supported so it makes no difference what is selected. 29 P a g e

30 14. Getting your root CA security certificate Now get the root CA certificate. This is the certificate that is placed on AACC/ACCS store as well as any client or server which requires a secure connection to AACC/ACCS Press Home then select Download a CA certificate, certificate chain, or CRL. Download the CA certificate and save it. 30 P a g e

31 15. Importing Certificates to AACC/ACCS Now that you have both certificates, place them on the server in a folder and follow following steps: Launch Security Manager Go to the Add Certificate Tab The automatic add option is the default option selected Browse to the folder where the certificates are. Select the folder You should see the certificates listed on the screen. Check they are the correct ones and if so select Add all Certificates button 31 P a g e

32 You will see a message indicating the success or failure of the import. To check go to Display Certificates tab to view the certificates in the store 15.1 Important Information on the Store At this stage, you have the store populated with the Identity and root certificates and once the server is restarted any services configured to use secure communication will use these certificates to establish a secure connection. As mentioned already the store is backed up when created. If you wish to save the store now with its contents you need to back up again using the Store Maintenance tab and the backup facility in there. If you delete the store without backing up the latest operation (add or remove certificates, security changes) then this will be lost. You can reimport the certificates you created from the CSR by using the default backup which was made when the store was created. Restore this and re-import again and everything should be back to where you were. Security changes will have to be set again 32 P a g e

33 If you somehow delete all backups, even the default store creation one then recreating the store and attempting to import in the certificates will not work as a new store operation creates a new private key and CSR and will not match any Identity certificate created from the previous store as it will have a different private key. You will have to go through the entire signing operation again. Therefore, the automatic backup of the store was introduced to avoid this scenario. Think of this automatic backup as the last failsafe if the other backups are deleted by whatever actions. 33 P a g e

34 16. Configuring AES to Communicate with AACC While the AACC solution can be secured fully using the main AACC security store it is not mandatory in all but two cases: o The AES server Required for SIP-CTI. o Agent controls browser application Required if used (Web Sockets). If the customer decides not to secure the solutions services and communicate over unencrypted channels, there is one mandatory connection that requires a secure connection and there is no avoiding the need to configure AACC to allow secure connection to this connection. o This connection is the SIP-CTI to the AES server. o It is over Mutual TLS which requires an Identity server on both ends (AACC and AES) o It requires the use of a template which has Server and Client Authentication when signing the Identity certificates. o Security ON or OFF has no impact to this service. It is separate to that setting in Security Manager and is always secure regardless of the value set. While the Agent Control browser application is not a required service in some applications if it is to be used then o The customer must configure the AACC security store and have initially Security set to ON, apply the changes to CCMA Multimedia Web service level to establish a secure binding on the IIS web server. o Once that is in place the customer can turn Security to OFF and this allows unsecure communication but leaves the secure binding in place for this application. The next section will go through how to configure the mandatory secure connection which is AES. Like the previous section, we will be using our own CA Note: While in this example we are using the same CA for configuring the AACC and AES, there can be cases where a different CA is used in each server and thus requires that the root CA certificate is present in each server respective security store. Refer to section titled Example of MTLS Protocol Handshake to get a visual representation of what is required to establish a connection using multiple CA s. Log into the AES web interface 34 P a g e

35 Select Security Host AA Service Settings Check the TR/87 elements o Authenticate Client Cert with Trusted Certs o Require Trusted Host Entry 35 P a g e

36 Next Select Security Host AA Trusted Hosts There should be an entry in here whose Certificate CN or SubAltName field should be the same as the FQDN field on Security Manager application. This is case sensitive. Also, the other fields should be set to Title Value Service Type TR87 User Authentication Policy AUTHENTICATION_NOT_REQUIRED User Authorization Policy UNSRESTRICTED ACCESS See Security Manager Field to check and how it should match the AES entries just explained. Security Manager Full Computer Name (FQDN) field and AES s Certificate CN or SubAltName must match 36 P a g e

37 Next Select Security Certificate Management CA Trusted Certificates In this, you must place the Certificate Authority (CA) root security certificate that has signed the AACC Identity certificate. o Select the Import option on the page o Browse to where you have previously saved the CA root security certificate. o Give it an alias title that makes sense and can be used to identify later and to its purpose. o Hit Apply to add the root certificate to the store once selected. 37 P a g e

38 Next Select Security Certificate Management Server Certificates This is where you add the Identity Certificate (Server Certificate) for the SIP-CTI link which AACC will use to login agents, sets, etc. To generate a Certificate Signing Request (CSR) then select Add option and fill in the appropriate information Select aesservices from the Certificate Alias drop list options Fill in the rest of the information based on your needs. Sign the generated CSR 38 P a g e

39 In Security Certificate Management Server Certificates Pending Request you will see the generated request There are two options o Manual enrol this is where you go away, signed the CSR and place the resulting signed Identity certificate in a location and import it. o Select Auto Enroll if you use SCEP certificates. For this example, I am using the manual option Once you follow the simple steps you should now have a server certificate listed in the Security Certificate Management Server Certificates screen. Restart AES Restart AACC 39 P a g e

40 17. Checking AACC AES SIP-CTI link Once all servers are set up with the security certificates and the services are started on both ends the next step to determine if the link is up. The main application to check this is the SIP Gateway Management Client This can be reached from the start and Apps listing Launch the application and select Connect This will connect the various services and links and give a Green or Red status message indicating the status of the link. See below For this example, it is the CTI proxy link we are interested in. The link is good. 40 P a g e

41 When there is a problem The following would be shown: 41 P a g e

42 18. Troubleshooting AACC AES SIP-CTI link If there is an issue then there are several methods to determine the issue The AACC and AES logs. Each will have information on issues if any occur. The following information is AACC specific. The logs can be in the following location: D:\Avaya\Logs\CCMS Specifically, the logs to locate are: o CCMS_SGM_SipSp.log (SGM specific) o CCMS_SGM_SipSpCpp0 (C++ wrapper around SIP stack) o CCMS_SGM_SipRvCpp0 (SIP stack specific) Each of the log files represents the levels the contact server internal messaging goes through when establishing a connection, with hierarchy flow of SipSP SipSpCpp SipRvCpp0 where the SipRvCpp0 being at the transport level where the messages are received and sent out. Each log provides information, the SipRvCpp0 log is in ERROR mode only by default and while it will inform you of the error for additional information this should be configured to record DEBUG messages (Registry and Log4J configuration file change). This is turned off due to the level of logs recorded and is not advisable to enable on a running/live system. This is a diagnostic log only and only used when all other logs fail to give the information required to resolve the issue. The first file to check after the Gateway Management client CCMS_SGM_SipSp: The next file to check is CCMS_SGM_SipSpCpp0 42 P a g e

43 The previous file has shown that while the handshake has been instigated it has failed. The next log file to check is o o o CCMS_SGM_SipRvCpp0 (SIP stack specific) The default setting is ERROR only Below is the type of message you will see, there is not a lot of detail recorded while in ERROR only mode. but once it can be ascertained there is an issue then the level can be set to DEBUG once you understand the impact of turning this level of logging on the system (Large hard disk consumption if left on) To turn on full logging then change the following. Please note revert to default levels when the analysis is done In the Registry, go to o HKLM\System\CurrentControlSet\services\CCMS_SIP_Service\Parameters\JVMOpt ions and set / create -Dcom.nortel.contactcenter.sgm.RadvisionLogging o Set the key to 1 Open D:\Avaya\Contact Center\Manager Server\iccm\sgm\config\SGMCXXLogging and set the logging level to debug 43 P a g e

44 o <logger name="siprvlogger"> <!-- CCMS_SGM_SipRvCpp0 Config Option - Level Change the level value below to "error" to turn off logging for CCMS_SGM_SipRvCpp0.log or "debug" to turn it on. --> <level value="debug"/> <appender-ref ref="siprvlogcpp"/> </logger> Terminal connection o The following command which will indicate an issue where AES can block AACC from connecting. o Open putty (or some other TTY client) o Connect to the AES server o Enter in the following command: netstat taepon grep 4723 This will list all connections on that port. It should list the IP address of AACC if it is connected successfully or not. There is a TCP column and if there is a value, not 0 in there then AES has blocked AACC from the connection Stop AACC services, restart AES, once AES is back up then start AACC services and check the connection again If you do not see the AACC IP address in the list then there is a more fundamental issue where either AACC or AES security configuration is the problem. Check both again. Check the Host AA and Security Manager names match as this is the most common issue. Ensure the TR/87 checkboxes mentioned before are enabled. o Sample output from the putty command o Each line shows a connection to this particular AES and if it is established. o The blue box shows where it should be 0 value. Anything else means that AES is actively blocking the connection due to some configuration issue usually. 44 P a g e

45 Wireshark or some other network analyzer o This requires some knowledge of what to look for and how TLS handshakes work. o The main item to note is set the following on the analyzer to filter out all the other packets and isolate the TLS ones. Stop Services Open Wireshark On the Filter bar enter in the ip.src==xxx.xxx.xxx.xxx && ip.dst==xxx.xxx.xxx.xxx Where AACC is the src IP and AES is the dst IP. Ensure you apply the filter with the arrow on the right-hand side o Start the services on AACC o You should capture the following trace with those filters. Note no real information yet but the SYN packet you see can be decoded to show the TLS handshake. Currently, Wireshark is not set up for that. Look for the RST packet and that should indicate there is an issue. 45 P a g e

46 So, select that first SYN packet and right select it and pick Decode As option The following dialog will be displayed, go to the current field and select SSL from it and Save 46 P a g e

47 Now you can see the TLS handshake packets. The screenshot below is an example of a bad TLS handshake with the issue being clearly stated Unknown CA after applying that Decode As option In this case, there is a missing root CA certificate on AACC server. AES has sent over its Identity (server) certificate to AACC, AACC has tried to check if it trusts it, it cannot find the root CA certificate in its list and therefore rejects the handshake. 47 P a g e

48 Solution: Add the root CA certificate that the AES has used to sign its Identity certificate to the AACC security store. 48 P a g e

49 19. Setting the security levels for the Contact Center The newly created store now contains the necessary certificates to enable the various applications and services in the contact center. Creating the store alone will not necessarily meet the individual customer s requirements and there is a tab called Security Configuration which will allow the customer to change the default security settings which are set when the store was created. See below for default settings There are two sections to this tab. Web Services Security Level (Status) This is essentially an ON or OFF switch o o o When OFF No secure communication is set and any service or application governed by this will communicate over TCP or HTTP based on their transport requirements. When ON - Secure communication is set and any service or application governed by this will communicate over TLS or HTTPS based on their transport requirements. Note: SIP and CTI Signaling Level in the other section labelled TLSv1 Protocol Level Settings is not influenced by the ON/OFF switch on AACC since it requires TLS for SIP-CTI always. 49 P a g e

50 TLSv1 Protocol Level Settings Sets the TLSv1 level certain services operate on. o o o There are three distinct areas which govern the TLSv1 level each will use if the main security level is set to ON. SIP and CTI Signaling Level Levels for SIP signaling and CTI traffic CCMA Multimedia Web Services Level Sets the levels for all the Windows operating systems including IIS. All windows based technology applications are influenced by this setting as it sets the Windows registry to raise or lower the TLS level. Event Broker Web Service Level Levels for EBWS web services. Each setting is individual and distinct from each other and requires security to be ON. 50 P a g e

51 20. Example of security setting changes When set to ON and the Apply button is set Security Manager triggers a series of commands which pushes the content and settings of the security store and security manager settings to the various services and web servers on the AACC/ACCS server. Following explains what it does for the IIS Web Server. o When set to Security ON. The root CA certificate(s) is placed on the Trusted Root Certificate Authorities area on the Windows OS 51 P a g e

52 When set to ON and the Apply button is set Security Manager triggers a series of commands which pushes the content and settings of the security store and security manager settings to the various services and web servers on the AACC/ACCS server. Following explains what it does for the IIS Web Server. o When set to Security ON. The Identity certificate is placed into the Personal Certificates section on Windows OS It then creates an HTTPS binding with port 443 with the Contact Center SSL certificate alias from the store set to be used when an HTTPS request comes in. The SSL settings on IIS is set to Require SSL which enforces HTTPS 52 P a g e

53 Note some folders under the Default Web Site have this check box unchecked to allow HTTP requests, applications such as Agent Desktop One click requires that the user can download the latest AAD without requiring a secure connection. When set to Security OFF o While it seems logical to remove the binding and reset IIS to allow HTTP traffic only there are several applications and services that require TLS and so even when security is set to OFF the Binding remains in place with HTTPS/443 and the security certificate in place to allow certain applications to continue to function. o What is changed is the SSL Settings checkbox is unchecked which allows HTTP as well as HTTPS traffic. Only when the store is deleted from Security Manager application is the entire IIS configuration cleaned up, the binding is removed, the certificates are removed from the settings and HTTP is only allowed. 53 P a g e

54 21. What else is configured automatically The example above explains IIS automatic configuration when the Security level is set. There are other web servers and services changed also o Tom Cat web server o JETTY web server o CXF web server That covers most of the services and applications on the Contact Server 54 P a g e

55 22. What's not covered by the store There are services that are not governed by the main contact center security store. SOA Open Interfaces This has its own store and user interface to allow the customer to create a store, CSR and import into the SOA store to establish secure communication for the SOA OI. 55 P a g e

56 23. CCT OI and CCMS TLS Configuration The CCT OI and CCMS OI interfaces do not use the common contact center store and hence do not use Security Manager for their configuration. CCT OI is configured using CCT Console tool and CCMS OI is configured using the Server Configuration tool. These tools configure: o Webservice ON/OFF o TLS ON/OFF TLS levels o Cert configuration The cert store is the same for CCMS OI and CCT OI, hence certificate configuration can be performed using either tool. Both the CCT OI and CCMS OI interfaces are disabled by default. If these interfaces are not in use they should not be enabled and hence TLS configuration is not required. If High Availability is in use, note that the Hostname must be updated before CSR generation. For further details, please see CCT OI and CCMS OI High availability considerations section. 56 P a g e

57 24. CCT OI Enable TLS Launch CCT Console o o o Check Enable CCT Web Services checkbox If not already check TLS Security checkbox Set Min TLS Level to the minimum TLS level which needs to be supported. 57 P a g e

58 25. Generate CSR Click the Generate CSR button o A popup will be displayed o Input the following details: Location Company Name Password o Accept the recommended Key length and Hashing algorithm unless there is a requirement to use the other versions. o When these details are correct, click the Generate button Note this will cause the keystore to be created: D:\Avaya\Contact Center\Common Components\CMF\security\server.keystore And the CSR to be created: D:\Avaya\Contact Center\Common Components\CMF\security\csr.cer 58 P a g e

59 26. Use CSR The generated CSR is stored in the location indicated in the text box under the Generate CSR button D:\Avaya\Contact Center\Common Components\CMF\security\csr.cer The contents of this file are used to obtain an Identity certificate as described earlier in this document. 59 P a g e

60 27. Import CA Certificate Once the CSR has been generated the next step is to import the trusted CA cert. o o o o Enter an alias for the CA cert in the CA Alias text box Click Import Trusted CA Certificate button A popup will launch from which you can browse to the file system location of the CA cert Note after import the step 3 Import certificate button has become enabled 27.1 After Importing CA cert 60 P a g e

61 28. Import Signed Cert Now that that CA cert has been imported the signed cert can now be imported Click the Import Certificate button o A popup will launch from which you can browse to the file system location of the signed cert After import note that the Step 1,2 and 3 buttons have become disabled and TLS is now fully configured Note that the keystore is located here: o D:\Avaya\Contact Center\Common Components\CMF\security 61 P a g e

62 29. TLS Fully Configured 62 P a g e

63 30. Resetting TLS configuration Note that the keystore is located here: o D:\Avaya\Contact Center\Common Components\CMF\security\server.keystore If there was a mistake made with the CSR generation the TLS configuration can be reset using the Reset TLS Encryption Configuration button. Please note that the reset will delete the keystore, requiring all the TLS configuration steps to be completed again The reset operation saves the keystore and CSR in the following location, which may be useful for recovery if TLS is reset by accident: o D:\Avaya\Contact Center\Common Components\CMF\security\backups o Within a folder named using current date and time o Note this folder may not be preserved on service pack upgrades Please note that the above backup is only created if the Reset TLS button is used. If the keystore is removed by any other means there is no backup 63 P a g e

64 31. CCMS OI TLS configuration The CCMS OI web services encompass Open Networking OI and Open Queue OI These web services are configured using the Server Configuration tool If these interfaces are not in use they will be disabled by default and hence there is no need to configure TLS To enable these interfaces launch Server Configuration o Select WS Open Interface from the left-hand pane o Check the SOA ENABLED checkbox o Check TLS Encryption checkbox o Select the desired TLS level, note this setting in the Server Configuration interface will only apply to the Open Networking OI and Open Queue OI interfaces. CSR generation, CA cert importation, and signed cert importation are like the steps already outlined for CCT OI. Also, note since the cert store is the same as used for CCT OI the CCT Console interface can be used to configure these certs instead of Server Configuration The next screenshot shows the Server Configuration interface before any configuration has been performed The following section then shows the Server Configuration interface after TLS has been enabled and certs fully configured Note that since the cert store is shared with CCT OI its possible for this TLS Configuration to show as FULLY_CONFIGURED even when the CCMS OI webservices are disabled or do not use TLS 64 P a g e

65 31.1 CCMS OI before TLS configuration 65 P a g e

66 31.2 CCMS OI after TLS configuration 66 P a g e

67 32. CCT OI and CCMS OI High availability considerations There is no place in either configuration interface (CCT Console of Server Configuration) to enter SAN s For High Availability solutions which make use of a Managed name the Managed name must be used for the cert creation, this is configured using Server Configuration In the host section when High Availability is not in use this host should be the server name, this is the default, for example, if my server name is SERVERNAME: When High Availability is in use the host must be changed from the default server name to instead be the managed name, for example, if my managed name is MANAGEDNAME I would update the entry as follows: 67 P a g e

68 33. ACC 7.X SSO Setup with System Manager 7.X The following details how to integrate ACC with System Manager to facilitate Single Sign-On (SSO). For additional information on the deployment of System Manager please refer to the appropriate documentation. Initial Setup o Deploy System Manager o Power up System Manager o Add System Manager FQDN and IP to AACC hosts file o Navigate to System Manager via the secure URL o Log in as admin, Change the default password System Manager Password Reset steps if required: Separately, via console: o Log in to System Manager as root/root01 o Edit /etc/hosts to add AACC with correct domain info: o 10.xxx.xxx.xxx aacc70test5 68 P a g e

69 Ensure the ACC server is in the same domain as SM if not already 69 P a g e

70 Ensure that the relevant domain is captured in Browser Compatibility View Settings Ensure that both System Manager and ACC are members of Trusted Sites in Internet Explorer 70 P a g e

71 The following is most likely the first result you will see when attempting to access System Manager Continue to this website and view the Certificate and the Certification Path tab 71 P a g e

72 In this case, the CA Root certificate is not trusted, so View Certificate and Install to Trusted Root Certification Authorities store as advised: 72 P a g e

73 In this case, the CA Root certificate is not trusted, so View Certificate and Install to Trusted Root Certification Authorities store as advised: 73 P a g e

74 Security Store configuration o Previous instructions on store creation have covered in detail the steps described here, please refer to those sections for detail. o Shut down services This is required to allow AACC security store to be deleted o Launch Certificate Manager/Security Manager o On Certificate Store tab Delete Store to delete any previous store. o Fill in the necessary information and create the store to create the CSR. o Take the CSR being displayed and copy it. 74 P a g e

75 Signing the ACC CSR using System Manager using Agent Certificate Configuration snap-in o Open the Agent Certificate Configuration snap-in o Populate details of the system manager o Select the CSR created from within Certificate Manager/Security Manager in the previous step. o Click Process Request to create signed certificates in Avaya\Contact Center\Common Components\CCKeyStore as shown below 75 P a g e

76 Take the generated security certificates from SM and import them into the ACC store using Security Manager. Turn on Security and restart ACC as advised. After restart o o Ensure all services are up With SSO disabled via Manager Administration Security Settings snap-in, ensure that you can navigate directly as follows: Both above tests are successful 76 P a g e

77 Some common mistakes o o Date/Time mismatch Simply ensure that the ACC has the same time and date as the System Manager o o o o Enable security (SSO) via Security Details snap-in Save Enable Wait for security to enable Test SSO 77 P a g e

78 o o o o Restart Browser. Navigate to Note that you automatically get re-directed to SSO Login with System Manager admin credentials as shown below o You should be logged in automatically to CCMA with no access as shown below o o This proves SSO working correctly with System Manager. A next Step would be to use the CCMA User Migration utility to map System Manager User accounts to Unassigned CCMA Users. At that point, logging in as the mapped System Manager User should re-direct to CCMA with the correct account credentials, and associated Access Partition Management rights. 78 P a g e