Skip to end of metadata
Go to start of metadata

Description

Describes SSL Offload functionality, including SSL Domain Certificates, SSL Certificate Chains, Ciphers, and SSL Offload Profiles.

Content / Solution:

SSL Offload allows you to set up a Virtual Listener to handle the work of converting external SSL/HTTPS traffic into normal HTTP traffic, instead of having encryption/decryption handled by the web server. By taking the computing burden off of the web servers, server performance can be significantly improved. With SSL Offload, you can set up a Virtual Listener to accept SSL traffic, decrypt the traffic prior to it being transmitted to the nodes in the virtual listener pool, and encrypt the corresponding outbound traffic coming from the nodes back to the connecting users. The servers within the pool don’t bear the encryption load, and the certificate and keys can be managed centrally on the Virtual Listener. 

Terminology Overview:

Setting up SSL Offload requires multiple objects. Here is an explanation of the terminology and concepts:


  • SSL Domain Certificate
    • This is a proprietary CloudControl term that represents the pairing of the SSL Certificate for a domain name and the associated private key. Although most SSL implementations treat these as separate objects, both the certificate and private key are required to set up an SSL Offload Profile on a Virtual Listener. Therefore, CloudControl pairs them as a single object made up of two elements:
      1. The SSL Certificate itself - tied to the organization's domain (i.e. www.foo.com or a wildcard such as *.foo.com)
      2. The RSA private "key" associated with the certificate
  • SSL Certificate Chain
    • Unless the SSL certificate for the domain was issued by a root Certificate Authority, there is a series of intermediate certificates that form a "chain" that ties the Domain Certificate to a trusted Certificate Authority.
    • CloudControl treats the entire chain of certificates as a single object, so users provide the entire "chain" of certificates as an input
  • Cipher
    • There are a wide variety of different ciphers available to support SSL encryption. With the SSL protocol, the "client" that is connecting to the HTTPS URL negotiates a cipher based on what the "server" will support. In the context of SSL Offload, the Cipher variable defines which ciphers are accepted and the order in which they are preferred. Ciphers are long strings defining the preference order and which cipher are allowed and which are prohibited
      • Example: MEDIUM:HIGH:!EXPORT:!ADH:!MD5:!RC4:!SSLv2:!SSLv3:!3DES:!TLSv1:!ECDHE:!ECDH_RSA:!ECDH_ECDSA:!ECDHE_ECDSA:@SPEED
    • It is not required that you define this string for each SSL Offload Profile. Each data center location has a "default cipher" string that will be used if the cipher is not explicitly defined. The default cipher should work for most purposes. The default cipher is listed in the Data Center Specifications section of the Data Center Dashboard - See How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location
  • SSL Offload Profile
    • The SSL Offload Profile is the object that implements SSL Offload on a specific Network Domain. An SSL Offload Profile identifies the 2-3 objects to be used for SSL Offload:
      1. SSL Domain Certificate (required)
      2. SSL Certificate Chain (optional)
      3. Cipher (required, though the system will insert the default cipher if it isn't explicitly defined):
    • Once the SSL Offload Profile is created, it is associated with a Virtual Listener and the Virtual Listener will then use the objects described by the SSL Offload Profile when accepting SSL traffic. The same SSL Offload Profile can be used on multiple Virtual Listeners on the same Network Domain. 
      • Example: If you set up the SSL Profile using a "wildcard" SSL Domain certificate that supports multiple subdomains, you could use that same profile on multiple Virtual Listeners which correspond to the different subdomains.

Configuring SSL Offload 

Corresponding to the objects described above, enabling SSL Offload on a Virtual Listener is a multi-step process, though not all steps are required for each configuration. Here is an overview of the steps involved assuming you have already configured a Virtual Listener that is set up to answer to HTTPS traffic on Port 443 and that Virtual Listener is set up to pass that traffic onto the nodes in the pool on an unencrypted port:


  1. Upload an SSL Domain Certificate
    1. You need to upload the SSL certificate and associated private key onto the Network Domain. The system will upload it into the infrastructure and make it available for use in an SSL Offload Profile as described in the third step below. 
    2. For details, see How to Manage SSL Domain Certificates
  2. Upload an SSL Certificate Chain (if needed)
    1. If your SSL Domain Certificate is not from a Certificate Authority (CA) and requires one or more intermediate certificates to establish a chain to a CA, you will need to upload all of these certificates as a single object.
    2. For details, see How to Manage SSL Certificate Chains
  3. Create an SSL Offload Profile
    1. You now create an SSL Offload Profile that defines the SSL Domain Certificate, any SSL Certificate Chain, and the Cipher to be used by a Virtual Listener.
    2. For details, see How to Manage SSL Offload Profiles
  4. Associate the SSL Offload Profile to a Virtual Listener
    1. You can now associate the SSL Offload Profile with the Virtual Listener and SSL Offload will commence automatically based on the inputs defined by the SSL Offload Profile.
    2. NOTE: Since SSL Certificates operate based on domain names, successful use of this function assumes you have set up DNS for the associated subdomain to point to the Virtual Listener IP address.
    3. For details on how to add SSL Offload to an existing Virtual Listener, see How to Manage Virtual Listeners on a Network Domain
    4. You can also add an SSL Offload Profile when creating a new Virtual Listener as described in How to Create a Virtual Listener on a Network Domain

Additional Notes about SSL Offload Capabilities

  • When creating an SSL Domain Certificate, the system:
  • Note that due to the sensitive nature of the data, CloudControl will not "remember" the details on the inputs for an SSL Domain Certificate. It accepts the inputs, validates them, installs them on the infrastructure, and then wipes all details of the specifics from its records. You will not be able to view those inputs again, so ensure your name and description inputs provide you with the details you need to identify the SSL Domain Certificate. 
    • This is also true of the SSL Certificate Chain
  • If you use the same SSL Domain Certificates or SSL Certificate Chains across multiple Network Domains, you will need to upload them separately to each Network Domain. You cannot re-use an SSL Domain Certificate across multiple Network Domains.
  • SSL Offload will reduce the IP traffic directed to the nodes by eliminating the SSL handshake overhead. If connections with the SSL endpoint transmit relatively small amounts of information (i.e. close to the size of the certificate information being transmitted by the protocol), this can eliminate a significant percentage of traffic to the nodes. However, note that Inbound and Outbound bandwidth usage will still include all such overhead. For more details, see Introduction to Usage Reporting.

Recently Updated