Adding an HTTPS Listener

Scenarios

HTTPS listeners are best suited for applications that require encrypted transmission. Load balancers decrypt HTTPS requests before routing them to backend servers, which then send the processed requests back to load balancers for encryption before they are sent to clients.

Constraints

Adding an HTTPS Listener to a Dedicated Load Balancer

  1. Log in to the management console.
  2. In the upper left corner of the page, click and select the desired region and project.
  3. Click in the upper left corner to display Service List and choose Network > Elastic Load Balancing.
  4. Locate the load balancer and click its name.
  5. Under Listeners, click Add Listener. Configure the parameters based on Table 1.
    Table 1 Parameters for configuring a listener

    Parameter

    Description

    Example Value

    Name

    Specifies the listener name.

    listener-pnqy

    Frontend Protocol

    Specifies the protocol that will be used by the load balancer to receive requests from clients.

    HTTPS

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

    80

    SSL Authentication

    Specifies how you want the clients and backend servers to be authenticated.

    There are two options: One-way authentication or Mutual authentication.

    • If only server authentication is required, select One-way authentication.
    • If you want the clients and the load balancer to authenticate each other, select Mutual authentication. Only authenticated clients will be allowed to access the load balancer.

    One-way authentication

    Server Certificate

    Specifies the certificate that will be used by the backend server to authenticate the client when HTTPS is used as the frontend protocol.

    Both the certificate and private key are required.

    For details, see Creating, Modifying, or Deleting a Certificate.

    N/A

    CA Certificate

    Specifies the certificate that will be used by the backend server to authenticate the client when HTTPS is used as the frontend protocol.

    A CA certificate is issued by a certificate authority (CA) and used to verify the certificate issuer. If HTTPS mutual authentication is required, HTTPS connections can be established only when the client provides a certificate issued by a specific CA.

    For details, see Creating, Modifying, or Deleting a Certificate.

    N/A

    Enable SNI

    Specifies whether to enable SNI when HTTPS is used as the frontend protocol.

    SNI is an extension to TLS and is used when a server uses multiple domain names and certificates.

    This allows the client to submit the domain name information while sending an SSL handshake request. After the load balancer receives the request, the load balancer queries the corresponding certificate based on the domain name and returns it to the client. If no certificate is found, the load balancer will return the default certificate. For details, see SNI Certificate (for HTTPS Listeners).

    N/A

    SNI Certificate

    Specifies the certificate associated with the domain name when the frontend protocol is HTTPS and SNI is enabled.

    Select an existing certificate or create one.

    For details, see Creating, Modifying, or Deleting a Certificate.

    N/A

    Access Control

    Specifies how access to the listener is controlled. The following options are available (for details, see Access Control):

    • All IP addresses
    • Blacklist
    • Whitelist

    Whitelist

    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 Creating an IP Address Group.

    ipGroup-b2

    Transfer Client IP Address

    Specifies whether to transmit IP addresses of the clients to backend servers.

    This function is enabled for dedicated load balancers by default and cannot be disabled.

    Enabled

    Advanced Forwarding

    Specifies whether to enable the advanced forwarding policy. You can add advanced forwarding policies to HTTP or HTTPS listeners to forward requests to different backend server groups based on HTTP request method, HTTP header, query string, or CIDR block in addition to domain names and URLs.

    Enabled

    Advanced Settings

    Security Policy

    Specifies the security policy you can use if you select HTTPS as the frontend protocol. For more information, see TLS Security Policy.

    TLS-1-0

    HTTP/2

    Specifies whether you want to use HTTP/2 if you select HTTPS for Frontend Protocol. For details, see HTTP/2.

    N/A

    Transfer Load Balancer EIP

    Specifies whether to store the EIP bound to the load balancer in the X-Forwarded-ELB-IP header field and pass this field to backend servers.

    N/A

    Idle Timeout

    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.

    60

    Request Timeout

    Specifies the length of time (in seconds) after which the load balancer closes the connection if the load balancer does not receive a request from the client.

    The request timeout duration ranges from 1 to 300.

    60

    Response Timeout

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

    60

    Tag

    Adds tags to the listener. Each tag is a key-value pair, and the tag key is unique.

    N/A

    Description

    Provides supplementary information about the listener.

    You can enter a maximum of 255 characters.

    N/A
  6. Click Next: Configure Request Routing Policy.
    1. You are advised to select an existing backend server group.
    2. You can also click Create new to create a backend server group and configure parameters as described in Table 2.
    Table 2 Parameters for configuring a backend server group

    Parameter

    Description

    Example Value

    Backend Server Group

    Specifies a group of servers with the same features to receive requests from the load balancer. Two options are available:

    • Create new
    • Use existing
      NOTE:

      To associate an existing backend server group, ensure that it is not in use. Select the backend server group with the correct protocol. For example, if the frontend protocol is TCP, the backend protocol must be TCP.

    Create new

    Backend Server Group Name

    Specifies the name of the backend server group.

    server_group-sq4v

    Backend Protocol

    Specifies the protocol that will be used by backend servers to receive requests.

    The backend protocol can be HTTP or HTTPS and changed be changed between the two options.

    HTTP

    Load Balancing Algorithm

    Specifies the algorithm that will be used by the load balancer to distribute traffic. The following options are available:

    • Weighted round robin: Requests are routed to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests.
    • Weighted least connections: In addition to the number of active connections established with each backend server, each server is assigned a weight based on their processing capability. Requests are routed to the server with the lowest connections-to-weight ratio.
    • Source IP hash: The source IP address of each request is calculated using the consistent hashing algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key is used to allocate the client to a particular server. This allows requests from different clients to be routed based on source IP addresses and ensures that a client is directed to the same server that it was using previously.
    NOTE:
    • Choose an appropriate algorithm based on your requirements for better traffic distribution.
    • For Weighted round robin or Weighted least connections, no requests will be routed to a server with a weight of 0.

    Weighted round robin

    Sticky Session

    Specifies whether to enable sticky sessions. If you enable sticky sessions, all requests from a client during one session are sent to the same backend server.

    This parameter is optional and can be enabled only if you have selected Weighted round robin for Load Balancing Algorithm.

    N/A

    Sticky Session Type

    Specifies the type of sticky sessions for HTTP and HTTPS listeners.

    • Load balancer cookie: The load balancer generates a cookie after receiving a request from the client. All subsequent requests with the same cookie are routed to the same backend server.

    Load balancer cookie

    Stickiness Duration (min)

    Specifies the minutes that sticky sessions are maintained. You can enable sticky sessions only if you select Weighted round robin for Load Balancing Algorithm.

    • Stickiness duration at Layer 4: 1 to 60
    • Stickiness duration at Layer 7: 1 to 1440

    20

    Slow Start

    Specifies whether to enable slow start, which is disabled by default.

    After you enable slow start, the load balancer linearly increases the proportion of requests to send to backend servers in this mode. When the slow start duration elapses, the load balancer sends full share of requests to backend servers and exits the slow start mode.

    For details, see Slow Start (Dedicated Load Balancers).

    N/A

    Slow Start Duration

    Specifies how long the slow start will last.

    The duration ranges from 30 to 1200, in seconds, and the default value is 30.

    30

    Description

    Provides supplementary information about the backend server group.

    You can enter a maximum of 255 characters.

    N/A
  7. Click Next: Add Backend Server. Add backend servers and configure health check for the backend server group. For details about how to add backend servers, see Overview. For details about how to configure health check parameters, see Table 3.
    Table 3 Parameters for configuring a health check

    Parameter

    Description

    Example Value

    Health Check

    Specifies whether to enable health checks.

    If the health check is enabled, click next to Advanced Settings to set health check parameters.

    N/A

    Advanced Settings

    Health Check Protocol

    Specifies the protocol that will be used by the load balancer to check the health of backend servers.

    If the backend protocol is HTTP or HTTPS, the health check protocol can be TCP, HTTP, or HTTPS.

    HTTP

    Domain Name

    Specifies the domain name that will be used for health checks.

    This parameter is available when you set the health check protocol to HTTP or HTTPS.

    • You can use the private IP address of the backend server as the domain name.
    • You can also specify a domain name that consists of at least two labels separated by periods (.). Use only letters, digits, and hyphens (-). Do not start or end strings with a hyphen. Max total: 100 characters. Max label: 63 characters.

    www.elb.com

    Health Check Port

    Specifies the port that will be used by the load balancer to check the health of backend servers. The port number ranges from 1 to 65535.

    NOTE:

    This parameter is optional. If you do not specify a health check port, a port of the backend server will be used for health checks by default. If you specify a port, it will be used for health checks.

    80

    Path

    Specifies the health check URL, which is the destination on backend servers for health checks. This parameter is available only when you set the health check protocol to HTTP or HTTPS. The path must start with a slash (/) and can contain 1 to 80 characters.

    The path can contain letters, digits, hyphens (-), slashes (/), periods (.), percent signs (%), ampersands (&), and the following special characters: _~';@$*+,=!:()

    NOTE:

    Example:

    If the URL is http://www.example.com/chat/try/, the health check path is /chat/try/.

    If the URL is http://192.168.63.187:9096/chat/index.html, the health check path is /chat/index.html.

    /index.html

    Interval (s)

    Specifies the maximum time between two consecutive health checks, in seconds.

    The interval ranges from 1 to 50.

    5

    Timeout (s)

    Specifies the maximum time required for waiting for a response from the health check, in seconds. The timeout duration ranges from 1 to 50.

    3

    Maximum Retries

    Specifies the maximum number of health check retries. The value ranges from 1 to 10.

    3
  8. Click Next: Confirm.
  9. Confirm the configuration and click Submit.

Adding an HTTPS Listener to a Shared Load Balancer

  1. Log in to the management console.
  2. In the upper left corner of the page, click and select the desired region and project.
  3. Click in the upper left corner to display Service List and choose Network > Elastic Load Balancing.
  4. Locate the load balancer and click its name.
  5. Under Listeners, click Add Listener. Configure the parameters based on Table 4.
    Table 4 Parameters for configuring a listener for a shared enhanced load balancer

    Parameter

    Description

    Example Value

    Name

    Specifies the listener name.

    listener-pnqy

    Frontend Protocol

    Specifies the protocol that will be used by the load balancer to receive requests from clients.

    HTTPS

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

    80

    SSL Authentication

    Specifies whether how you want the clients and backend servers to be authenticated.

    There are two options: One-way authentication or Mutual authentication.

    • If only server authentication is required, select One-way authentication.
    • If you want the clients and the load balancer to authenticate each other, select Mutual authentication. Only authenticated clients will be allowed to access the load balancer.

    One-way authentication

    CA Certificate

    Specifies the certificate used by the server to authenticate the client when HTTPS is used as the frontend protocol.

    For details, see Creating, Modifying, or Deleting a Certificate.

    N/A

    Server Certificate

    Specifies the certificate used by the server to authenticate the client when HTTPS is used as the frontend protocol.

    Both the certificate and private key are required.

    For details, see Creating, Modifying, or Deleting a Certificate.

    N/A

    Enable SNI

    Specifies whether to enable SNI when HTTPS is used as the frontend protocol.

    SNI is an extension to TLS and is used when a server uses multiple domain names and certificates.

    This allows the client to submit the domain name information while sending an SSL handshake request. After the load balancer receives the request, the load balancer queries the corresponding certificate based on the domain name and returns it to the client. If no certificate is found, the load balancer will return the default certificate. For details, see SNI Certificate (for HTTPS Listeners).

    N/A

    SNI Certificate

    Specifies the certificate associated with the domain name when the frontend protocol is HTTPS and SNI is enabled.

    Select an existing certificate or create one.

    For details, see Creating, Modifying, or Deleting a Certificate.

    N/A

    Access Control

    Specifies how access to the listener is controlled. The following options are available (for details, see Access Control):

    • All IP addresses
    • Blacklist
    • Whitelist

    Whitelist

    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 Creating an IP Address Group.

    ipGroup-b2

    Transfer Client IP Address

    Specifies whether to transmit IP addresses of the clients to backend servers.

    This function is enabled by default and cannot be disabled.

    Enabled

    Advanced Settings

    Security Policy

    Specifies the security policy you can use if you select HTTPS as the frontend protocol. There are four options. For more information, see TLS Security Policy.

    TLS-1-2

    HTTP/2

    Specifies whether you want to use HTTP/2 if you select HTTPS for Frontend Protocol. For details, see HTTP/2.

    N/A

    Transfer Load Balancer EIP

    Specifies whether to store the EIP bound to the load balancer in the X-Forwarded-ELB-IP header field and pass this field to backend servers.

    Enable this option if you want to transparently transmit the EIP of the load balancer to backend servers.

    N/A

    Idle Timeout

    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.

    60

    Request Timeout

    Specifies the length of time (in seconds) after which the load balancer closes the connection if the load balancer does not receive a request from the client.

    The request timeout duration ranges from 1 to 300.

    60

    Response Timeout

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

    60

    Tag

    Adds tags to the listener. Each tag is a key-value pair, and the tag key is unique.

    N/A

    Description

    Provides supplementary information about the listener.

    You can enter a maximum of 255 characters.

    N/A
  6. Click Next: Configure Request Routing Policy. Table 5 describes the parameters for configuring a backend server group.
    Table 5 Parameters for adding a backend server group

    Parameter

    Description

    Example Value

    Backend Server Group

    Specifies a group of servers with the same features to receive requests from the load balancer. Two options are available:

    • Create new
    • Use existing
      NOTE:

      To associate an existing backend server group, ensure that it is not in use. Select the backend server group with the correct protocol. For example, if the frontend protocol is TCP, the backend protocol can only be TCP.

    Create new

    Backend Server Group Name

    Specifies the name of the backend server group.

    server_group-sq4v

    Backend Protocol

    Specifies the protocol used by backend servers to receive requests.

    The backend protocol is HTTP by default and cannot be changed.

    HTTP

    Load Balancing Algorithm

    Specifies the algorithm used by the load balancer to distribute traffic. The following options are available:

    • Weighted round robin: Requests are routed to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests.
    • Weighted least connections: In addition to the number of active connections established with each backend server, each server is assigned a weight based on their processing capability. Requests are routed to the server with the lowest connections-to-weight ratio.
    • Source IP hash: The source IP address of each request is calculated using the consistent hashing algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key is used to allocate the client to a particular server. This allows requests from different clients to be routed based on source IP addresses and ensures that a client is directed to the same server that it was using previously.
    NOTE:
    • Choose an appropriate algorithm based on your requirements for better traffic distribution.
    • For Weighted round robin or Weighted least connections, no requests will be routed to a server with a weight of 0.

    Weighted round robin

    Sticky Session

    Specifies whether to enable sticky sessions. If you enable sticky sessions, all requests from a client during one session are sent to the same backend server.

    NOTE:

    You can enable sticky sessions only if you have selected Weighted round robin for Load Balancing Algorithm.

    N/A

    Sticky Session Type

    Specifies the type of sticky sessions for HTTP and HTTPS listeners.

    • Load balancer cookie: The load balancer generates a cookie after receiving a request from the client. All subsequent requests with the same cookie are routed to the same backend server.
    • Application cookie: The application deployed on the backend server generates a cookie after receiving the first request from the client. All subsequent requests with the same cookie are routed to the same backend server.

    Load balancer cookie

    Cookie Name

    Specifies the cookie name. If you select Application cookie, enter a cookie name.

    cookieName-qsps

    Description

    Provides supplementary information about the backend server group.

    You can enter a maximum of 255 characters.

    N/A
  7. Click Next: Add Backend Server. Add backend servers and configure health check for the backend server group. For details about how to add backend servers, see Overview. For details about how to configure health check parameters, see Table 6.
    Table 6 Parameters for configuring a health check

    Parameter

    Description

    Example Value

    Health Check

    Specifies whether to enable health checks.

    If the health check is enabled, click next to Advanced Settings to set health check parameters.

    N/A

    Advanced Settings

    Health Check Protocol

    Specifies the protocol that will be used by the load balancer to check the health of backend servers. There are two options: TCP and HTTP.

    HTTP

    Domain Name

    Specifies the domain name that will be used for health checks.

    This parameter is available when the health check protocol is HTTP.

    • You can use the private IP address of the backend server as the domain name.
    • You can also specify a domain name that consists of at least two labels separated by periods (.). Use only letters, digits, and hyphens (-). Do not start or end strings with a hyphen. Max total: 100 characters. Max label: 63 characters.

    www.elb.com

    Health Check Port

    Specifies the port that will be used by the load balancer to check the health of backend servers. The port number ranges from 1 to 65535.

    NOTE:

    By default, the service port on each backend server is used. You can also specify a port for health checks.

    80

    Path

    Specifies the health check URL.

    This parameter is available when the health check protocol is HTTP. The path can contain 1 to 80 characters and must start with a slash (/).

    The path can contain letters, digits, hyphens (-), slashes (/), periods (.), question marks (?), percent signs (%), ampersands (&), and underscores (_).

    NOTE:

    Example:

    If the URL is http://www.example.com/chat/try/, the health check path is /chat/try/.

    If the URL is http://192.168.63.187:9096/chat/index.html, the health check path is /chat/index.html.

    /index.html

    Interval (s)

    Specifies the maximum time between two consecutive health checks, in seconds.

    The interval ranges from 1 to 50.

    5

    Timeout (s)

    Specifies the maximum time required for waiting for a response from the health check, in seconds. The timeout duration ranges from 1 to 50.

    3

    Maximum Retries

    Specifies the maximum number of health check retries. The value ranges from 1 to 10.

    3
  8. Click Next: Confirm.
  9. Confirm the configuration and click Submit.
Parent topic: Listener