Adding an HTTPS Listener

Scenarios

You can add an HTTPS listener if you require encrypted transmission. Load balancers decrypt HTTPS requests before routing them to backend servers. Once the servers process the requests, they send them back to the load balancers for encryption. Finally, the load balancers send the encrypted requests to the clients.

When you add an HTTPS listener, ensure that the subnet of the load balancer has sufficient IP addresses. If the IP addresses are insufficient, add more subnets on the summary page of the load balancer. After you select a subnet, do not configure network ACL rules for this subnet. If rules are configured, access to the load balancer may be denied.

Constraints

If the listener protocol is HTTPS, the protocol of the backend server group is HTTP by default and cannot be changed.

Procedure

1. Go to the load balancer list page.
2. On the displayed page, locate the load balancer and click its name.
3. Under Listeners, click Add Listener. Configure the parameters based on Table 1.

   Table 1 Parameters for configuring an HTTPS listener

   Parameter	Description
   Frontend Protocol	Specifies the protocol that will be used by the load balancer to receive requests from clients. Select HTTPS.
   Listening Port	Specifies the port that will be used by the load balancer to receive requests from clients. The port number ranges from 1 to 65535.
   IP Address Group	Specifies the IP address group associated with a whitelist or blacklist. If there is no IP address group, create one first. For more information, see IP Address Group.
   Transfer Client IP Address	Transfer Client IP Address is enabled by default for HTTPS listeners. When you use an HTTPS listener to forward requests, you can use the X-Forwarded-For header to transfer client IP addresses. The first IP address recorded in the X-Forwarded-For header is the client IP address. For details, see Transfer Client IP Address.
   Configure Certificate
   SSL Authentication	Specifies whether how you want the clients and backend servers to be authenticated. One-way authentication: Backend servers will be authenticated by clients. Mutual authentication: The clients and backend servers will authenticate each other.
   Server Certificate	Specifies a server certificate that will be used to authenticate the server when HTTPS is used as the frontend protocol. Both the certificate and private key are required.
   CA Certificate	Specifies the certificate that will be used to authenticate the client when SSL Authentication is set to Mutual authentication and the frontend protocol is HTTPS. CA certificates are also called client CA public key certificate. They are used to verify the issuer of a client certificate. HTTPS connections can only be established when the client provides a certificate issued by a specific CA.
   SNI	Server Name Indication (SNI) is an extension to TLS. It allows clients to specify which domain name of a listener they are trying to connect in the first request. Once receiving the request, the load balancer searches for the certificate based on the domain name. The client includes the domain name in the initial SSL handshake. Once receiving the request, the load balancer searches for the certificate based on the domain name. If an SNI certificate is found, this certificate will be used for authentication. If no SNI certificates are found, the server certificate is used for authentication. For details, see Using SNI Certificates for Access Through Multiple Domain Names.
   SNI Certificate	Specifies one or more certificates associated with the domain name when the frontend protocol is HTTPS and SNI is enabled. You can only select the server certificate with SNI domain names.
   More (Optional)
   Security Policy	Specifies the security policy you can use if you select HTTPS as the frontend protocol. For more information, see TLS Security Policy.
   HTTP/2	Specifies whether you want to use HTTP/2 if you select HTTPS for Frontend Protocol. For details, see Enabling HTTP/2 for Faster Communication.
   Idle Timeout (s)	Specifies the length of time for a connection to keep alive, in seconds. If no request is received within this period, the load balancer closes the connection and establishes a new one with the client when the next request arrives. The idle timeout duration ranges from 0 to 4000.
   Request Timeout (s)	Specifies the length of time that a load balancer is willing to wait for a client request to complete. The load balancer terminates the connection if a request takes too long to complete. The request timeout duration ranges from 1 to 300.
   Response Timeout (s)	Specifies the length of time (in seconds) after which the load balancer sends a 504 Gateway Timeout error to the client if the load balancer receives no response from the backend server after routing a request to the backend server and receives no response after attempting to route the same request to other backend servers. The response timeout duration ranges from 1 to 300. NOTE: If you have enabled sticky sessions and the backend server does not respond within the response timeout duration, the load balancer returns 504 Gateway Timeout to the clients.
   Tag	Adds tags to the listener. Each tag is a key-value pair, and the tag key is unique.
   Description	Provides supplementary information about the listener. You can enter a maximum of 255 characters.
   HTTP Headers	Rewrite X-Forwarded-ELB-IP to transfer the load balancer EIP.

4. Click Next: Configure Request Routing Policy.
   1. You are advised to select an existing backend server group.
   2. You can also select Create new to create a backend server group.
      1. Configure the backend server group based on Table 2.
      2. Click Next: Add Backend Server. Add backend servers and configure a health check for the backend server group.

         For details about how to add backend servers, see Backend Server Overview. For the parameters required for configuring a health check, see Table 3.

5. Click Next: Confirm.
6. Confirm the configurations and click Submit.