How SSL Protocol Acceleration Works

How SSL works

SSL is the standard protocol for establishing a secure encrypted link between a remote application server and the client Web browser on the local user computer. The SSL protocol secures each session link by automatically establishing connections on-demand using standards-based protocols, encryption techniques, and certificate exchange.

SSL encryption requires a certificate on the server to authenticate the identity of a server. A certificate is an electronic confirmation that you, as the owner of a public key, are who you claim to be, and that you hold the private key corresponding to the public key in the certificate.

You create this certificate by generating a certificate and sending a certificate signing request to a Certificate Authority (CA) using your public key. The CA checks with a registration authority to verify your identity and then signs and returns the certificate. You then upload the signed certificate and public key onto the server.

When a client browser visits a web site hosted on the server over HTTPS, the server offers the signed certificate and public key. The client browser verifies that the certificate is valid for the site that is being visited and that it has not expired. Then it will verify the chain of trust by looking at who has signed the certificate:

  • If the certificate is a root-certificate, it will compare it against the ones shipped with the OS or browser.
  • If it is a non-root-certificate, it will follow the chain of trust up each level until reaching a root-certificate.

Now the server has the private key and the client has the public key effectively creating a private encrypted tunnel that allows them to appropriately communicate by encrypting and decrypting the traffic between them. When the session is over, the connection is automatically terminated.

There are other certificate signing options

You can create a self-signed certificate, where the certificate has signed itself and therefore there is no chain of trust. The browser will issue a warning, telling the user that the site certificate cannot be verified. To continue, the user will have to confirm that they trust the site. When the browser visits this site again later, the warning will not be presented again since the user has already confirmed their trust of the site. An alternate use case, is the company that created the self-signed certificate can provide the certificate to the client users and tell them to load the certificate into their browsers. This is equivalent to confirming trust when the warning is shown. Using self-signed certificates is reasonable in situations where you want encryption but you do not need the third party verification, such as an internal system where you want your internal users to have password protection, however as the clients and the server are behind a firewall so you do not need the third party verification.

You can create your own self-signed CA certificate for signing other certificates. In this case, the certificates that your self-signed CA certificate signs will have no chain of trust. Similar to self-signed certificates, using your own self-signed CA certificate to sign other certificates is reasonable in situations where you want encryption but you do not need the third party verification. The difference is that a warning is shown to the client for each server when using self-signed certificates, whereas when using a self-signed CA certificate to sign multiple other certificates, the warning will only be shown once for all the certificates that were signed by the CA certificate, that is, once the client trusts a certificate that is signed by the self-signed CA certificate, the client automatically trusts all other certificates signed by that self-signed CA certificate.

In the case where there are multiple virtual hosts on a single server, a Server Name Indication (SNI) is used to indicate what virtual hostname the client is attempting to connect to during the handshaking process. This allows a single server to present individual certificates for each of its multiple secure websites without requiring all of the sites to use the same certificate.

How Exinda accelerates the SSL protocol

For SSL acceleration, a server-side Exinda appliance and a client-side appliance is put in line for this SSL traffic. The traffic between these appliances are accelerated. The benefits that can be gained by generic application acceleration on encrypted data are limited. For example, the Exinda WAN Memory technology achieves higher reductionmeasures the amount of redundant data that has been removed from the network, increasing capacity on clear text rather than encrypted data. However, the SSL acceleration feature is designed to overcome these limitations by transparently decrypting accelerated traffic, performing the relevant application acceleration techniques such as TCP Acceleration and WAN Memory, then re-encrypting the traffic again. This means Exinda can apply all application acceleration technologies to the traffic as if it were clear text, while still maintaining SSL connections.

The server-side appliance will act on behalf of the client in the communication between the appliance and the server and the client-side appliance will act on behalf of the server for communication between the client and the appliance. In order to decrypt and re-encrypt the traffic, the Exinda appliances must have access to the appropriate certificate and public key for each server that clients will communicate with over SSL. Furthermore, the Exinda appliances must be configured to know which servers can receive traffic that is SSL accelerated. These servers are defined by IP address and port, certificate, and other details. Only traffic to servers that are explicitly configured in this way is SSL accelerated. If the server is hosting multiple virtual hosts, when defining the server, you can define an acceleration server for each of the virtual hosts by specifying the SNI virtual host so that the virtual host name is presented during the handshake process with the appliance.


If you upload the appropriate certificates and configure SSL Acceleration Servers on the server-side appliance, the appliance will use the Exinda acceleration community feature to push these certificates and server configurations to the other appliances in the community. Configurations that have been pushed to the remote appliances will appear in the Remote SSL Acceleration Servers list on the Optimization > SSL page.

By default, the Exinda appliances are pre-loaded with several root CA certificates. The site-specific certificates will be loaded onto the appliances by the user (or distributed using the community feature). When the client attempts to access the website, during the handshake, the appliance sends to the client all of the certificates in the chain of trust.


If you are concerned about any decrypted data on the Exinda appliance, then you can choose to use storage disk encryption.