Configuring SSL Offloading Using the CLI

This section describes how to configure the SSL offloading profile on the CLI.

Prerequisites

A local certificate (real server certificate) has been imported. The certificate must contain a key. Usually, you can obtain the local certificate from the server administrator.
The CA certificate corresponding to the client has been imported. It is mandatory for the SSL bidirectional authentication scenario. Usually, you can obtain the CA certificate from the server administrator.
The CRL has been imported. It is optional for the SSL bidirectional authentication scenario. Usually, you can obtain the CRL from the server administrator.

For the preceding import operations, see Configuring PKI-CLI.

Procedure

Access the SLB view from the system view.
slb
Create an SSL offloading profile and access the profile view.
ssl-profile [ ssl-profile-id ] ssl-profile-name
Optional: Configure a description for the SSL offloading profile.
description description-string
Specify an SSL server certificate. The certificate must be an existing local certificate on the device.
server-certificate server-certificate-name

You can specify only one SSL server certificate for each SSL offloading profile.

If SSL offloading is performed on the firewall and the local certificate of the server is issued by a multi-level CA, you need to import both the local certificate and the multi-level CA certificate to the firewall. After the local certificate is referenced, the firewall sends the local certificate and CA certificate chain to the client. The client uses the complete CA certificate chain to verify the validity of the local certificate. Otherwise, a certificate security alarm or connection failure may occur during SSL handshake due to the lack of a complete certificate chain.
Specify an SSL protocol version. Keeping the configuration consistent with that on the real server is recommended. For special requirements, you can specify a version other than that on the real server.
ssl-version { tls1.0 | tls1.1 | tls1.2 } ^*

TLS 1.0 and TLS 1.1 have security risks. TLS 1.2 and higher versions are recommended.
Specify an SSL cipher suite. Keeping the configuration consistent with that on the real server is recommended. For special requirements, you can specify a cipher suite other than that on the real server.
ssl-algorithm { medium | high | ssl-algorithm-string }
- high: Select this cipher suite for the scenario with high security requirements. The cipher suite may not be properly compatible with browsers in early versions.
- medium: This cipher suite is compatible with most browsers but is not highly secure.
- ssl-algorithm-string: Enter a user-defined cipher suite, for example, DHE-RSA-AES128-SHA:AES128-SHA:AES128-SHA256:DHE-RSA-AES128-SHA256.
Configure the FW to cache SSL sessions. Caching SSL sessions can reduce SSL handshake overheads. However, caching many sessions for a long time may waste session resources on the device, degrading performance.
- Set the maximum number of cached SSL sessions.
  
  session-cache number cache-num
- Set a timeout period for cached SSL sessions.
  
  session-cache timeout cache-time
Optional: Configure client authentication.
1. Enable client authentication. In the SSL bidirectional authentication scenario, if the server needs to verify the client certificate, enable this function.
  client-auth enable
2. Specify a CA certificate. In the SSL bidirectional authentication scenario, the device uses this CA certificate to verify the certificate sent from the client.
  ca-certificate ca-certificate-file
3. Optional: Specify the maximum number of levels a CA certificate can have. If the used CA certificate is not a root CA certificate, the device checks the validity of the superior CAs one by one.
  ca-chain-depth depth
4. Optional: Specify a CRL. The device checks whether the client certificate is in the CRL to verify its validity.
  crl crl-file

Follow-up Procedure

When configuring server load balancing, if SSL offloading is required, you must run the protocol https command and then the ssl profile ssl-profile-name command to reference the SSL offloading profile configured here. For details, see Configuring a Virtual Service.

As server certificates are applied for based on domain names, one domain name corresponds to one certificate. The SSL offloading profile can reference only one certificate. Therefore, one virtual server address (domain name) can correspond to only one SSL offloading profile. If there are multiple virtual server addresses for SSL offloading, configure multiple virtual servers.
One SSL offloading profile can be referenced by multiple virtual servers.
To allow clients to access intranet servers, you must configure a security policy for access from the Untrust zone to the security zone of the real server with the destination address being the virtual server address, service being https, and action being permit.