The process for adding an SSL-enabled Virtual Service is the same for a regular Virtual Service. First, add the Virtual Service. In the main menu of the LoadMaster WUI, select Virtual Services and Add New. A screen will appear asking to enter the Virtual Address, Port, Service Name and Protocol.

The port defaults to port 80, which is the standard HTTP port. If an SSL-enabled Virtual Service is being created, change the port to 443, which is the default HTTPS port. Keep the protocol as tcp, and click Add this Virtual Service.

The Virtual Service properties screen will appear. Among the various sections in this screen is SSL Properties.

To enable SSL for this Virtual Service, select the Enabled check box.

A warning will appear saying that a temporary certificate will be used for the service. Click OK.

As soon as SSL is enabled, the LoadMaster will install a self-signed certificate for the Virtual Service.

The check boxes in the Supported Protocols section allow you to specify which protocols should be supported by the Virtual Service. By default, TLS1.1, TLS1.2, and TLS1.3 protocols 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.

Selecting the require Server Name Identifier (SNI) hostname check box means that the hostname will always be required to be sent in the TLS client hello message.

When Require SNI hostname is disabled, the first certificate in the list of Assigned Certificates as a host header match is not found.

When Require SNI hostname is enabled, a certificate with a matching host name must be found, otherwise the connection is dropped. This also supports wildcard certificates.

Multiple certificates are supported. Wildcard certificates work regardless of what position they are in. SNI can find certificates by Subject Alternative Name (SAN) when the certificate is not in the first position. SNI will choose the first matching certificate in a list if multiple certificates contain the same name in either the Common Name or SAN name.

Note: When using a Subject Alternative Name (SAN) certificate, alternate source names are not matched against the host header.

Note: Wildcard certificates are supported but please note that the root domain name will not be matched as per RFC 2459. Only anything to the left of the dot will be matched. Additional certificates must be added to match the root domain names. For example, www.kemptechnologies.com will be matched until a wildcard of *.kemptechnologies.com. Kemptechnologies.com will not be matched.

After you have added certificates to the LoadMaster (see the Adding an SSL Certificate section) you can assign one or more certificates to the Virtual Service by selecting them in the Available Certificates list, clicking the right arrow and clicking the Set Certificates button. Both internal and external certificates can be assigned to the same Virtual Service.

There is a limit of 8171 characters when assigning certificates to a Virtual Service using the WUI.

A description of each of the options in the Client Certificates drop-down is provided below:

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

By default the LoadMaster will accept HTTPS requests from any client. Selecting any of the other values below will require all clients to present a valid client certificate. In addition, the LoadMaster can also pass information about the certificate to the application.

Note: This option should not be changed from the default of No Client Certificates required. Only change from the default option if you are sure that all clients that access this service have valid client certificates.

  • 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.

Real Servers can be added to this SSL Virtual Service by clicking Add New in the Real Servers section.

When adding Real Servers, ensure to add them on port 80 (or whatever port that the non-SSL service is running on), and not port 443.