# Genesys Quality Management Suite 8.1.520 : Secure Web Access for PCI-DSS Compliance

Created and last modified by

Genesys Genesys Quality Management Suite installs a web server (Apache Tomcat 6.x) to run webbased applications such as Call Recording Web GUI and Quality Manager. By default, Tomcat is not configured to provide secure (HTTPS) access via a Secure Socket Layer (SSL) implementation, but this is required for PCI-DSS compliance.

## Component Compatibility

Some Genesys Quality Management Suite components require HTTP connectivity alongside secure HTTPS. Review the following before deciding whether to deploy only HTTPS , or both HTTPS and HTTP protocols in parallel.

- CUCM-based Prerecording: Requires HTTP as well as HTTPS due to a CUCM limitation.
- Live Monitoring: Works with HTTPS with no additional configuration (HTTP not required).
- Screen Capture: Currently requires HTTP as well as HTTPS. Although the Screen Capture Capture Client communicates via TLS to the Screen Capture Server (SRS), HTTP is required for communication from the Client to the Screen Capture Media Upload Server.

## Configuration

Use a commercial CA Certificate Authority, such as Thawte or Verisign, to sign the SSL certificates. Using a commercial CA avoids browser warnings regarding ‘untrustworthy’ self-signed certificates.

The following steps cover the procedure to configure secure web access using both commercially signed and self-signed SSL certificates. Tomcat 6.0 contains the Tomcat Native APR library, recommended for production use. However, use of this library prevents the use of the java `keytool` utility for key and certificate generation; the OpenSSL utility must be used instead as covered here.

## Creating the Key and Certificate

To generate an RSA private key, use an SSH Client.Log in as `admin`. Enter `su` - to log in as the root user. Enter the password, the default is `zoomcallrec`. Enter the following command:

    $ openssl genrsa 1024 > localhost.key
    $ chmod 400 localhost.key

Obtain a commercially signed certificate or create a self-signed certificate.

### Obtaining a Commercially Signed Certificate

To obtain a commercially signed certificate:

1. Create the certificate signing request file (`cert.csr` in PEM format); answer all questions, including the required challenge password for identification:

       $ openssl req -new -nodes -sha1 -key localhost.key > cert.csr

2. Send the certificate signing request file `cert.csr` to the CA.
3. After receiving the signed certificate, save it as `localhost.crt` on the server in the same location as the private key.

4. Copy the key and certificate into place and change the file ownership using the following command:

       $ cp localhost.key /opt/callrec/web/conf
       $ cp localhost.crt /opt/callrec/web/conf
       $ chown callrec:callrec /opt/callrec/web/conf/localhost.*

### Creating a Self-signed Certificate

To create a self-signed certificate, answer all the questions for the certificate data as below.

The Common Name certificate parameter must contain the FQDN name of the server, for example, `callrec.mycompany.com`.

    openssl req -new -x509 -nodes -sha1 -days 365 -key localhost.key > localhost.crt
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [GB]:US
    State or Province Name (full name) [Berkshire]:California
    Locality Name (eg, city) [Newbury]:San Francisco
    Organization Name (eg, company) [My Company Ltd]:MyCompany, Inc.
    Organizational Unit Name (eg, section) []:IT
    Common Name (eg, your name or your server's hostname) []:callrec.mycompany.com
    Email Address []:it-callrec@mycompany.com

Copy the key and certificate into place and change the file ownership using the following command:

    $ cp localhost.key /opt/callrec/web/conf
    $ cp localhost.crt /opt/callrec/web/conf
    $ chown callrec:callrec /opt/callrec/web/conf/localhost.*

## Converting the Certificate

The signed certificate can be converted from an alternative format to PEM format (`.crt, .cer` filetypes) using openssl, for example, the following converts a DER encoded certificate file (`cert.cer`) into PEM format (`localhost.crt`):

    openssl x509 -inform der -in cert.cer -out localhost.crt

For further information and conversion examples, see the OpenSSL documentation: http://www.openssl.org/docs/apps/x509.html and SSL Shopper site: https://www.sslshopper.com/ssl-converter.html.

## Configuring Tomcat

Use an SSH Client.Log in as admin. Enter `su -` to log in as the root user. Enter the password, the default is `zoomcallrec`.

1. Edit the config file at `/opt/callrec/web/conf/server.xml` to include the following <`Connector`> port node definition (paste within the <`Service name=”Catalina”`> node service definition):

       <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" SSLEnabled="true" SSLCertificateFile="${catalina.base}/conf/localhost.crt" SSLCertificateKeyFile="${catalina.base}/conf/localhost.key" />

   To specify the version of the SSL protocol used, add the following option into the Connector port configuration (see http://tomcat.apache.org/tomcat-6.0-doc/apr.html#HTTPS for details):

       SSLProtocol="SSLv3"

   To disable unsecured HTTP access, comment out the http connector pointing to port 8080 in the file `/opt/callrec/web/conf/server.xml`:

       <!--
       <Connector port="8080" protocol="HTTP/1.1"
       connectionTimeout="20000"
       redirectPort="8443" />
       -->

## Restarting the Call Recording Web Service

1. After completing configuration, restart the Call Recording web service:

       /opt/callrec/bin/rc.callrec_web restart

2. Observe the web server log `at /var/log/callrec/web.log` for any errors.
3. If the web server restarts successfully, and no serious errors are apparent in the server log:
   If the web server is not accessible, try to access using the original non-secure http URL; if necessary re-enabling non-secure access if it was disabled earlier. Troubleshoot the`/var/log/callrec/web.log` log file for further indication of any issues.

## Adding the Localhost Certificate to the Java CA Certificates

Use the Java `keytool` utility to add the new `localhost.crt` certificate to the collection of trusted Certification Authorities (CA). Change the `–alias` parameter value (`callrecssl`) if required:

    keytool -keystore /usr/java/jdk1.6.0_35/jre/lib/security/cacerts -alias callrecssl -importcert -file /opt/callrec/web/conf/localhost.crt

Enter the default keystore password `changeit`.

Ensure the displayed certificate information is correct and type `y` to trust the certificate.

For more information on the `keytool` utility, including how to change the keystore password, see: http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html.

## Adding the Port Redirect to the IP Tables

At this point, SSL access is functional, but a port (:8443) is always required in the Call Recording server URL. Adding an SSL port redirect rule to the Linux IP Tables configuration via the following procedure removes this requirement:

1. Add redirect rule to existing IP Tables, replace `10.9.8.7` with the Call Recording server IP address:

       iptables -t nat -A PREROUTING -d 10.9.8.7 -p tcp --dport 443 -j REDI
       RECT --to-ports 8443

2. List (and note) updated IP Tables:

       iptables -t nat -L -v -n

3. Save updated IP Tables records:

       /etc/init.d/iptables save

4. Restart IP Tables:

       /etc/init.d/iptables restart

5. Check and compare updated IP Tables:

       iptables -t nat -L -v -n

6. Restart the web server:

       /opt/callrec/bin/rc.callrec_web stop /opt/callrec/bi
       n/rc.callrec_web start

7. The Call Recording web server should now be accessible at the URL:
   `https://<SERVER_IP>` without a port being specified; for example, `https://10.9.8.7`

## Configuring the Quality Manager Stream URL Setting

When secure access to the Call Recording Web GUI is finalized, update the URL to Call Recording stream parameter. Navigate to Settings > Configuration > ScoreCARD > Basic Setup section to enable Quality Manager to correctly play media over the secure connection. Enter the server address and specify port 8443 (mandatory).

The Call Recording stream parameter is the same URL used to access the Call Recording Web GUI over https, for example:
`https://<FQDN>/callrec:8443`

At this point, SSL access should be working for all Genesys Quality Management Suite Tomcat-based web applications.

More information on setting up SSL in Apache Tomcat: http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html#Troubleshooting.

## Secure LDAP

The LDAPS (secure LDAP) protocol is the LDAP protocol running over an SSL connection. The application establishes an SSL connection with the LDAP server first, and then starts the LDAP bind/login attempt. This prevents attacks by sniffing for a password sent in plain text and "man in the middle" attacks by ensuring that the LDAP server is trusted.

Genesys Quality Management Suite supports LDAPS, but this needs to be configured manually, principally by the installation of appropriate SSL certificates. In this way, secure directory access contributes to fulfilling PCI-DSS directive #6.

If possible, it is helpful to configure and test a standard LDAP connection first before switching on LDAPS.

The following steps are required in order to set up secure LDAP within Call Recording.

## Install SSL Certificates

The java keytool supports X.509 certificates, so a commercial SSL certificate in this format is required. See the section on Secure Web Access for more information about certificates and format conversion.

To import the certificate using the keytool utility:

1. Upload the certificate file to the Call Recording server using scp, WinSCP or similar.
2. Run the command below, ensure it is entered on one line, and replace the following placeholders with their correct values:

- `[path_to_certificate]`: the full path to the certificate file uploaded to the server.
- `[store_pass]:` the keystore password; the default is: changeit.
- `[certificate_alias]:` a reference name for the certificate.

    /usr/java/default/bin/keytool -importcert -file [path_to_certificate] -keystore /usr/java/default/jre/lib/security/cacerts -storepass [store_pass] -alias [certificate_alias]

If there is a problem with the certificate, for example if it is not trusted, view the errors in the Call Recording UI log file, similar to the following sample:

    javax.naming.CommunicationException: simple bind failed: ldap.server.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
    PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to
    find valid certification path to requested target]

###
Enable LDAPS in the Call Recording Web GUI

Log in to the Call Recording Web GUI as an administrator, and navigate to Settings > Configuration > Web UI > LDAP.

1. Select the Use LDAPS protocol checkbox to enable LDAPS.
2. Ensure that the correct SSL IP port is entered into the Port field. The default LDAPS port is 636.

- Ensure the values for the remaining fields are correct.

- Save the modifications, then restart the web server :

      /opt/callrec/bin/rc.callrec_web restart

- If the configuration is correct, import Call Recording users from the LDAP directory. Refer to the Adding Users from LDAP section in the Call Recording User Guide.

## Configuring a Reverse Proxy

The reverse proxy hides the real address of the Call Recording server and so protects against web attacks. The reverse proxy takes requests from the network and forwards them to the Call Recording Server using only certain ports.

To configure the reverse proxy:

Navigate to: Settings > Configuration > Web UI scroll down to External IP address/host settings.

Enter the following:

- Type the IP address of the proxy serve in the User Interface Proxy IP field.
- Type 80 or 8080, based on settings of proxy in the User Interface Proxy PORT field.
- Type the IP address of the proxy server in the API (Core) IP field.
- Type 30400 in the API (Core) PORT field.
- The IP address of the proxy server in the Configuration Service IP field.
- Type 30400 in the Configuration Service PORT field.

The reverse proxy has to forward traffic on port 30400 to the Call Recording server on port 30400.

For the network the UI will be on, for example, 10.10.10.10:80 and this is translated to 192.168.1.1:8080 behind the proxy. This means that Call Recording only works correctly on IP 10.10.10.10:80. Behind the proxy IP address 192.168.1.1:8080 not all functionality will be correct.

If a proxy is used then full functionality is only available on the network side of the proxy.