SSL Properties

SSL Acceleration

This check box appears when the criteria for SSL Acceleration have been met. Select this check box to activate SSL Acceleration.

Enabled: If the Enabled check box is selected and there is no certificate for the Virtual Service, you are prompted to install a certificate. You can add a certificate by clicking Manage Certificates and importing or adding a certificate.

Reencrypt: Selecting the Reencrypt check box re-encrypts the SSL data stream before sending it to the Real Server.

Reversed: Selecting this check box means that the data from the LoadMaster to the Real Server is re-encrypted. The input stream must not be encrypted, for example, the client sends HTTP port 80 traffic to the LoadMaster and the LoadMaster sends HTTPS port 443 traffic to the Real Server. This is only useful in connection with a separate Virtual Service which decrypts SSL traffic then uses this Virtual Service as a Real Service and loops data back to it. In this way, the client to Real Server data path is always encrypted on the wire.

Supported Protocols

The check boxes in the Supported Protocols section enable you to specify which protocols are supported by the Virtual Service. By default, TLS1.1, TLS1.2, and TLS1.3 are enabled and SSLv3 and TLS1.0 are disabled.

Starting with version 7.2.37, when re-encryption is enabled, the TLS version that can be negotiated between the LoadMaster and the Real Servers behind it are no longer constrained by the TLS version settings configured on the client side. All TLS versions and ciphers that are supported on the LoadMaster can be negotiated without restriction by Real Servers. In this way, the LoadMaster can, for example, provide strict security for client-side application access and still support server-side connections to legacy servers that only support specific, less secure, TLS versions, and ciphers. This is illustrated in the example below.

Server connections are only restricted by the configuration of the Real Servers, regardless of the TLS version selected on the client side. Each Real Server can be configured independently of the others. The LoadMaster negotiates connections according to the requirements of each Real Server.

Add Received Cipher Name

In LoadMaster version 7.2.52 and above, a new check box called Add Received Cipher Name was added. This option is disabled by default. When this option is enabled, the LoadMaster adds X-SSL headers containing client SSL information such as TLS version, TLS cipher, client certificate serial number, and SNI host as described in below table.

The information contained in these headers can be used in content rules by referencing the appropriate header name in the rule (see the table below). This allows you to make load balancing decisions based on, for example, the cipher used.

This information can also be useful, for example, as you maintain cipher sets over time; it allows you to see which ciphers are being used and can help you plan what ciphers to change or delete in the cipher sets. The Add Received Cipher Name check box must be enabled to use the headers in the table below in content rules.

Require SNI hostname

If require Server Name Indication (SNI) is selected, the hostname is always required to be sent in the TLS client hello message.

When Require SNI hostname is disabled, the first certificate is used if a host header match is not found.

When Require SNI hostname is enabled, a certificate with a matching common name must be found, otherwise an SSL error is yielded. Wildcard certificates are also supported with SNI.

Pass through SNI hostname

In LoadMaster firmware version 7.2.52 and above, when this option is enabled and when re-encrypting, the received SNI hostname is passed through as the SNI to be used to connect to the Real Server. If the Virtual Server has a Reencryption SNI Hostname set, this overrides the received SNI.

Certificates

Available certificates are listed in the Available Certificates select list on the left. To assign or unassign a certificate, select it and click the right or left arrow button. Then click Set Certificates. Multiple certificates can be selected by holding Ctrl on your keyboard and clicking each required certificate.

Clicking Manage Certificates brings you to the SSL Certificates screen.

If you add a certificate to the LoadMaster in version 7.2.51 or later (or in 7.2.48.3 LTS or a later LTS version) and then downgrade to 7.2.50 or an earlier version (or 7.2.48.2 LTS or an earlier version) - the certificate will not work. To work around this, create a backup of all SSL certificates before downgrading and then restore the certificates after downgrading (Certificates & Security > Backup/Restore Certs). If you forget to take the backup before downgrading: upgrade the firmware again, take the certificate backup, downgrade, and then restore the certificate backup.

Reencryption Client Certificate

With SSL connections, the LoadMaster gets a certificate from the client and also gets a certificate from the server. The LoadMaster transcribes the client certificate in a header and sends the data to the server. The server still expects a certificate. This is why it is preferable to install a pre-authenticated certificate in the LoadMaster.

Reencryption SNI Hostname

In LoadMaster firmware version 7.2.52 and above, it is possible to set a Reencryption SNI Hostname at the SubVS level. If this is set in a SubVS, this overrides the parent Virtual Service value and/or the received SNI value.

Cipher Set

A cipher is an algorithm for performing encryption or decryption.

Each Virtual Service (which has SSL Acceleration enabled) has a cipher set assigned to it. This can either be one of the system-defined cipher sets or a user-customized cipher set. You can select system-defined cipher sets to quickly and easily select and apply the relevant ciphers. You can create and modify custom cipher sets by clicking Modify Cipher Set.

Ciphers

The Ciphers list is read only and displays a list of the currently assigned ciphers. Clicking Modify Cipher Set brings you to the Cipher Set Management screen. This screen allows you to create new, and modify existing custom cipher sets.

TLS1.3 Cipher Sets

Select the cipher sets for the TLS1.3 protocol to be allowed using any combination of supported ciphers over an SSL-enabled Virtual Service. By default, the following three cipher sets are enabled:

• TLS_AES_256_GCM_SHA384

• TLS_CHACHA20_POLY1305_SHA256

• TLS_AES_128_GCM_SHA256

Client Certificates

• No Client Certificates required: enables the LoadMaster to accept HTTPS requests from any client. This is the recommended option.

By default the LoadMaster accepts HTTPS requests from any client. Selecting any of the other values below requires all clients to present a valid client certificate. In addition, the LoadMaster also passes information about the certificate to the application.

• Client Certificates required: requires that all clients forwarding a HTTPS request must present a valid client certificate.
• Client Certificates and add Headers: requires that all clients forwarding a HTTPS request must present a valid client certificate. The LoadMaster also passes information about the certificate to the application by adding headers. When a client certificate is used, the X-SSL-ClientSerialid header is set.
• The below options send the certificate in its original raw form. The different options let you specify the format that you want to send the certificate in:
  • Client Certificates and pass DER through as SSL-CLIENT-CERT
  • Client Certificates and pass DER through as X-CLIENT-CERT
  • Client Certificates and pass PEM through as SSL-CLIENT-CERT
  • Client Certificates and pass PEM through as X-CLIENT-CERT

If a Virtual Service:

• Has SSL Acceleration enabled, and

• Any of the client certificate required options with "pass through as SSL-CLIENT-CERT/X-CLIENT-CERT" is selected in the Client Certificates drop-down list, and

• A Delete Header rule is applied to that Virtual Service to delete the SSL/X-CLIENT-CERT header field, then

  The Delete Header content rule preserves the LoadMaster inserted client certificate header fields and removes any header with that name passed in by the client.

Verify Client using OCSP

Verify (using Online Certificate Status Protocol (OCSP)) that the client certificate is valid.

Strict Transport Security Header

Enable this option to add the Strict-Transport-Security header to all LoadMaster-generated messages (ESP and error messages). The options in this drop-down list are as follows:

• Don't add the Strict Transport Security Header

• Add the Strict Transport Security Header - no subdomains

• Add the Strict Transport Security Header - include subdomains

• Add the Strict Transport Security Header - no subdomains + preload

• Add the Strict Transport Security Header - include subdomains + preload

Intermediate Certificates

Prior to the Intermediate Certificates field being added to the SSL Properties section, there was no ability to assign intermediate or root certificates to a Virtual Service. The Certificate Authority (CA) for client certificates was kept in the global certificate store, so the following could occur:

• Client certificates from two different CAs are installed on the LoadMaster
• Client A presents a certificate issued from CA 1 and as a network administrator, you only want them to be able to access Virtual Service 1.
• Client B presents a certificate issued from CA 2 and as a network administrator, you only want them to be able to access Virtual Service 2.
• Because both client certificates are validated against the global LoadMaster trust store, client A is also allowed access to Virtual Service 2 and client B is also allowed access to Virtual Service 1.

The Intermediate Certificates field allows you to assign intermediate and root certificates to specific Virtual Services. This provides the ability to restrict access. It also enables control on what client certificates are eligible to be used when connecting to a service which is useful in environments with multiple client certificates signed by multiple authorities. For example, when this is configured correctly for the scenario above - Client A will only have access to Virtual Service 1 and Client B will only have access to Virtual Service 2.

To configure this, follow the steps below:

1. Upload the relevant certificates.

2. Then in the LoadMaster User Interface (UI), go to Virtual Services > View/Modify Services.

3. Click Modify on the relevant Virtual Service.

4. Expand the SSL Properties section.

5. Click Show Intermediate Certificates.

6. Select the relevant certificates from the boxes and click the arrows to remove/assign them from/to the Virtual Service.

7. Then, click Set Intermediate Certificates.