Using certificates with Session Persistence Server

The Session Persistence Server can use a certificate to encrypt the connection using SSL between the proxy and the devices, and also between the user and the web interface. Use a certificate signed by a 3rd party Certificate Authority (CA) or use a self-signed certificate. Starting in version 4.5.12, the Session Persistence Server installer generates a unique self-signed certificate that can be used to secure traffic.

Starting in version 4.5.12, new installations of Session Persistence Server default to a secure connection between the user and the web interface. However, if you are upgrading Session Persistence Server, installing newer versions does not override existing settings. The default setting for securing traffic between Clients and the server has not changed.

CA vs. self-signed certificates

A certificate from a CA is automatically trusted by browsers (including Velocity) and provides better security by authenticating the server as well as encrypting the traffic. There may be a cost associated with a CA certificate, though, including the time it takes to set it up. A self-signed certificate is created by the installer and has no additional cost. Using a self-signed certificate encrypts traffic, but does not authenticate the server. The self-signed certificate generated by the installer is primarily for encrypting the Session Persistence Server web interface traffic, and not device traffic. If you want to use SSL for device connections, you should use a CA certificate.

Most browsers do not recognize self-signed certificates as valid and display a warning message that the user must navigate past in order to see the page. For example, Chrome displays an error page and the user must click Advanced > Proceed to [address] (unsafe) to navigate to a page using a self-signed certificate. Installing the certificate on the computer that a user connects to the web interface will bypass this warning message. If you only plan on accessing the web interface from the local computer where Session Persistence Server is installed, the certificate is added to the Windows certificate store during the installation process. If you plan on accessing the web interface from a remote computer, you will either have to advance past the browser warning manually or install the self-signed certificate on the computer that a person uses to connect to the web interface.

  Pros Cons
CA certificate

  • Automatically trusted by browsers, including Velocity

  • Authenticates the server and encrypts traffic

  • Works for device connections and web interface connections

  • May cost money and time to set up
Self-signed certificate

  • Can be generated automatically during installation

  • Encrypts traffic

  • Works for web interface connections

  • Does not authenticate the server, so the user may see warnings that the connection is unsafe

  • The installer-generated certificate does not work for device connections

When you use a CA certificate, it must be in PEM format with separate files for the certificate and for the key. Different CAs provide different instructions on how to obtain a certificate; follow the instructions from the CA you choose. Generally, you generate the private key and certificate signing request (CSR), then you give the CSR to the CA, and the CA gives you a signed public certificate.

Make sure Session Persistence Server is installed and that the certificate and private key files are available. You must have administrator permissions on the computer in order to makes changes in the Program Files directory.

1.Name the certificate file servercert.pem and the key file serverkey.pem

2.Replace the existing certificate files with the new CA certificate and key file.

3.Use either the Text Window or the Configuration Wizard to turn on SSL. For more information, see Configuring the Session Persistence Server

If you are using the installer-generated certificates, you should only turn on SSL for the HTTPserver.