Configuration of Secure Connections
- 1 Configuration of Secure Connections
- 1.1 Standard Configuration
- 1.2 Configuring Secure Connections to Java/PSDK-Based Applications
- 1.3 Configuring Secure Connections to Message Server
- 1.4 Configuring Secure Connections to Configuration Server
- 1.5 Configuring Secure Connections Between LCA and Solution Control Server
- 1.6 Configuring Secure Connections Between Genesys Deployment Agent and its Clients
- 1.7 Configuring Secure HA Synchronization connections
- 1.8 Certificate Revocation Lists
- 1.9 Cipher Lists
- 1.10 Check for Certificate-Host Matching
After you generate the certificates and install them on the host computers, you must configure Genesys applications to use them on the connections that need to be secure. (By default, connections between Genesys applications are not secure.)
- The instructions in this chapter assume that you are adding Genesys Transport Layer Security (TLS) to existing connections of your Genesys 8.x environment—that is, that your applications have already been installed, properly configured, and associated with hosts and with each other. For information about configuring new hosts, applications, and associations between them, see the Framework Deployment Guide.
- If you are using Genesys components of previous releases, you must upgrade them to release 8.x before you can configure secure connections between them.
- Some components require additional steps to complete the configuration of secure connections. These steps are provided in the Deployment Guide for your particular product or component.
- An application can be both a server and a client application. In this case, they are configured both as a TLS server and a TLS client application. In this case, the same security certificate is used as both a server certificate and a client certificate.
You configure all secure connections in the same way, regardless of the types of participating client and server applications. The only exceptions are:
- 8.x releases of Genesys client applications that run on Windows and support TLS do not require client security certificates.
- Connections with Java-based applications—See Configuring Secure Connections to Java/PSDK-Based Applications.
- Configuration Server connections—See Configuring Secure Connections to Configuration Server.
- Local Control Agent connections—See Configuring Secure Connections Between LCA and Solution Control Server.
- Genesys Deployment Agent connections—See Configuring Secure Connections Between Genesys Deployment Agent and its Clients.
- High Availability synchronization connections-See Configuring High Availability Synchronization Connections.
Starting with release 8.1.3, Genesys Security Pack on UNIX supports security certificate chains, sending out the intermediate certificates with the root certificate. To enable this support, specify the multiple certificates in a comma-delimited list in the Certificate field when configuring TLS. The certificates are sent in the order in which they are specified.
Multiple Trusted CAs
Starting with release 8.0.0, Genesys Security Pack on UNIX supports multiple Trusted CA certificates for TLS connections. To enable this support, create a PEM file listing all of the certificates issued by the Trusted CAs. Then specify the full path to this file in the trusted-ca field when configuring TLS. As security circumstances and requirements change, you can modify the file by adding and removing certificates, or completely replace it by specifying a single Trusted CA.
To configure secure connections, perform the following steps:
|1. For all server applications, configure a new or existing server port for secure connections. A port must be secure before you can configure a secure connection to that port. [+] Show steps|
|2. (Optional) Enable mutual TLS on the server applications. In the options of each server application, set the tls-mutual configuration option to 1.|
| 3. Assign a certificate to be used by the server applications.
[+] Show steps
|4. If necessary, remove (unassign) a certificate from a host, application, or port. [+] Show steps|
|5. (Optional, but recommended) Configure each server application to use the host certificate (for non-Java based applications) or application certificate (for Java-based applications), as applicable. If you are configuring mutual TLS, you must also configure each participating client application to use that host certificate. [+] Show steps|
|6. Configure secure connections from the client applications. [+] Show steps|
Configuring Secure Connections to Java/PSDK-Based Applications
Secure connections to Java/PSDK-based applications (such as Universal Contact Server) are configured in the same way as described in Configuration Steps, with the following exception:
- If you are running Java/PSDK-based applications on the same host as C++-based applications, do not use the host certificate to secure data exchange at the application or port level. Although both types of applications use a .PEM file for their private key, the internal format differs—Java/PSDK uses PKCS#8 and C++ uses RSA. Instead, use the application's certificate to enable secure data exchange on all secure ports of that application.
Configuring Secure Connections to Message Server
Secure connections to Message Server are configured in the same way as described in Configuration Steps, with the following exceptions:
- Message Server must configure its default port with the security settings if TLS is to be enabled. TLS configuration on secondary listening ports is not supported.
- The client establishing a connection to Message Server must configure the certificate information at the Application or connection level.
Message Server supports TLS communication between it and the Solution Control Servers in a distributed configuration. In this situation, Message Server acts as the server and its port is configured as secured. The Solution Control Servers then connect to this port.
Configuring Secure Connections to Configuration Server
To configure a secure connection of a client application to Configuration Server, complete the following procedures.
- Specify the Auto-Detect port number of Configuration Server during application installation, by using the Installation Wizard. The Installation Wizard will propagate these parameters to the following locations:
- To the Command–Line text box, in the Server Info section of the server’s Configuration tab.
- To the server application’s startServer.bat file (for Windows) or run.sh file (for UNIX).
- To the ImagePath in the Application folder in the Registry Editor.
- Modify a client application configuration by adding a connection to the Configuration Server Application object to the client, as described in step 6 of Configuring Secure Client Connections, but select the Auto-Detect port in step c.
Start the applications and enter the Auto-Detect port number of Configuration Server in the Log In dialog box that appears.
- Verify or create the Auto-Detect port of Configuration Server in the Configuration Server Application object.
- Modify a client application configuration by adding a connection to a Configuration Server Application object to the client, as described in step 6 of Configuring Secure Client Connections, but select the Auto-Detect port in step c.
- Depending on the method that you use for starting client applications, for existing client applications of server type, change the port information to correspond to the port ID of the Auto-Detect port that you specified for Configuration Server, as follows:
- In the Command Line Arguments text box in the Server Info section of the server’s Configuration tab.
- In the server application’s startServer.bat file (for Windows) or run.sh file (for UNIX).
- In the ImagePath in the Application folder in the Registry Editor.
Configuring Secure Connections Between LCA and Solution Control Server
A secure connection between Local Control Agent (LCA) and Solution Control Server (SCS) is optional, and requires that you modify the LCA configuration file and the Host object on which LCA is running.
Use the upgrade and lca-upgrade configuration options to configure secure data exchange using TLS on connections between LCA and SCS. These options are configured on the Host computer on which LCA and SCS are running, and where the certificate information is available to you.
For more information about these two options, refer to the Framework Configuration Options Reference Manual.
Before you configure the secure connection, you must:
- Install a certificate on the Host computer on which LCA is running.
- Have the certificate information available to you.
Sample Configuration Files for LCAThe following are sample configuration files for LCA in which the values of the upgrade options of the security section are set. [+] Show Files
Configuring Secure Connections Between Genesys Deployment Agent and its Clients
A secure connection between Genesys Deployment Agent and its clients is optional, and requires that you modify the Genesys Deployment Agent configuration file and the Host object on which Genesys Deployment Agent is running.
Use the tls and gda-tls configuration options to configure secure data exchange using TLS on connections between Genesys Deployment Agent and its clients. Refer to the Framework Configuration Options Reference Manual for detailed descriptions about these configuration options.
Before you start to configure the secure connections, you must ensure that:
- Certificates are installed on the Host computers on which Genesys Deployment Agent is running.
- The certificate information is available to you.
Sample Configuration Files for Genesys Deployment AgentThe following are sample configuration files for Genesys Deployment Agent,in which the values of the transport options in the [security] section are set. The settings are the same as any TLS setup, except that they are set in the configuration file instead of the configuration objects. [+] Show files
Configuring Secure HA Synchronization connections
This section describes how to configure secure connections between primary and backup servers in a high-availability (HA) configuration.
The HA synchronization connection is configured by selecting the HA sync check box in the Port Info dialog box of a specific port. This indicates that the port will be used by the former primary server to connect to the new primary server after a failover. If the HA sync check box is not selected, the former primary server will connect to the default port of the new primary server.
Certificate Revocation Lists
TLS uses digital certificates to identify the parties in a conversation and then to negotiate an encryption algorithm to use. If the certificates are revoked or expired, the connection will fail to identify the parties and TLS will not set up the encrypted channel.
A Certificate Revocation List (CRL) is a time-stamped list identifying revoked certificates. This list is signed by a CA or CRL issuer and is made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a system uses a certificate for verifying a remote user's digital signature, for example, that system not only checks the certificate signature and validity but also acquires a suitably-recent CRL and checks that the certificate serial number is not on that CRL. The meaning of “suitably-recent” may vary with local policy, but it usually means the most recently-issued CRL. A new CRL is issued on a regular periodic basis (such as hourly, daily, or weekly). An entry is added to the CRL as part of the next update following notification of revocation. An entry must not be removed from the CRL until it appears on one regularly-scheduled CRL issued beyond the revoked certificate's validity period.
Use the configuration option tls-crl (in the [security] section) to allow the supporting Genesys component to verify certificates against a CRL, by specifying a filename, in PEM format, that contains one or more certificates defining the Certificate Revocation List. Refer to the Framework Configuration Options Reference Manual for a full description of this option.
The cipher-list configuration option allows the supporting Genesys component to select a list of cipher suites used in TLS. This option is transferred to a third-party library and describes the set of possible cipher suites.
Cipher Formatting Rules
For applications using the Genesys common library, the cipher list string is a list of cipher operations. Each operation consists of an optional operator character followed by a name. Cipher list strings must conform to the following formatting rules:
- The name is either a valid cipher name or a cipher alias. Valid names contain the characters a-z, A-Z, 0-9, and -.
- List separator characters are used to separate the names and aliases in the list. A list separator character must be a colon.
- Multi-part names are joined with +.
- The character ! appearing immediately after a separator indicates a kill operation. The cipher following the character becomes unavailable.
- The character + appearing immediately after a separator indicates an order operation. This moves the active cipher to the current position in the list of ciphers.
- The character - appearing immediately after a separator indicates a delete operation. The cipher following the character becomes inactive. The cipher remains available for further operations.
- A non-operator character appearing immediately after a separator indicates an add operation. If the cipher following the character is not currently active, the cipher is added as an active cipher to the end of the list of available ciphers.
All operations occur in the order in which they appear in the list. If the cipher corresponding to a name (or part of a name, for multi-part names) is not available in the library, it is ignored during loading. In this situation, no error message is logged.
Ciphers also have aliases. The following table details the primary cipher aliases.
|kRSA, kDHr, kDHd, kEDH||Key exchange types|
|aRSA, aDSS, aNULL, aDH||Authentication|
|DES, 3DES, RC4, RC2, eNULL||Ciphers|
|MD5, SHA1||Message digests|
Groups of commonly-used ciphers also have aliases. This enables multiple aliases to be specified easily. The following table details the cipher group aliases.
|SSLv2||All SSLv2 ciphers|
|SSLv3||All SSLv3 ciphers|
|EXP||All export ciphers|
|LOW||All low strength ciphers (no export ciphers, normally single DES)|
Aliases can be joined in a colon-separated list to specify the ciphers to add, move, or delete.
The following string is an example of a cipher string:
This cipher string is interpreted in the following sequence:
- Do not consider any ciphers that do not authenticate.
- Use ciphers that use RC4 and RSA.
- Include the HIGH, MEDIUM, and LOW security ciphers.
- Add all export ciphers.
- Pull all SSLv2 and export ciphers to the end of the list.
Use the cipher-list option to define the list of ciphers. Refer to the Framework Configuration Options Reference Manual for a detailed description of the option.
If you are configuring a cipher list for an application using the Genesys common library, refer to the following:
- Cipher Formatting Rules for valid formats of a cipher list.
- Ciphers Example for an example of a valid cipher list.
If you are configuring a cipher list for an application using the PSDK library, refer to the Platform SDK Developer's Guide.
Check for Certificate-Host Matching
The tls-target-name-check option in the [security] section) enables a case-insensitive comparison of the TLS host name and the certificate’s subject field during the authentication process. This option is transferred to a third-party library and describes whether it is necessary or not to check the names.
Refer to Introduction to Genesys Transport Layer Security for details on authentication of TLS-Server and TLS-Client identity, which includes a step to check for certificate-host matching.
If the supporting Genesys component has a TLS-Client role for outbound connection and tls-target-name-check=no, then comparison of TLS-Server host name and the certificate’s subject field is not made. This is used in cases when some phone devices or programs have the certificate without the host name in subject field, but have a MAC-address or other information.
By default, a comparison is not made, and the connection is allowed. Refer to the Framework Configuration Options Reference Manual for a full description of this option.