If you want to encrypt data transmission for your application, you can create an HTTPS listener to forward HTTPS requests. HTTPS listeners support encrypted data transmission between Application Load Balancer (ALB) and clients that have SSL or TLS enabled.
Prerequisites
An ALB instance is created.
TLS security policies and at least one SSL server certificate are deployed on the ALB instance.
A server group is created.
Procedures
This topic describes two procedures that can be used to create an HTTPS listener. You can choose a method as needed.
Manual creation: You can create an HTTP listener and configure advanced features, such as mutual authentication.
Quick creation: You can use a template to quickly create an HTTP listener. You only need to specify a listener protocol, a listener port, a server certificate, and a backend server group.
Manual creation
Step 1: Create a listener
Log on to the ALB console.
In the top navigation bar, select the region in which the ALB instance resides.
Use one of the following methods to open the listener configuration wizard:
On the Instances page, find the ALB instance that you want to manage and click Create Listener in the Actions column.
On the Instances page, click the ID of the ALB instance that you want to manage. On the Listener tab, click Create Listener.
On the Configure Listener wizard page, set the following parameters and click Next.
Parameter
Description
Listener Protocol
Select a listener protocol.
In this example, HTTPS is selected.
Listener Port
Enter the port on which the ALB instance listens. The ALB instance listens on the port and forwards requests to backend servers. In this example, port 443 is used. In most cases, port 80 is used for HTTP and port 443 is used for HTTPS.
Valid values: 1 to 65535.
NoteThe listener ports of the same protocol must be unique within an ALB instance. The listener ports of HTTP and HTTPS must be different from each other.
Listener Name
Enter a name for the listener.
Tag
Configure the Tag Key and Tag Value parameters to add a tag. You can add one or more tags.
After you specify tags, you can filter listeners by tag on the Listener tab.
Advanced Settings
You can click Modify to configure the advanced settings.
Enable HTTP/2
Specify whether to enable HTTP/2 for the listener.
Idle Connection Timeout Period
Specify a timeout period for idle connections. Unit: seconds. Valid values: 1 to 600. Default value: 15. To specify a longer timeout period, go to the Quota Center console.
If no request is received within the specified timeout period, CLB closes the connection. When a request is received, CLB establishes a new connection.
NoteThis feature is unavailable for HTTP/2 requests.
Connection Request Timeout
Specify a request timeout period. Unit: seconds. Valid values: 1 to 600. Default value: 60. To specify a longer timeout period, go to the Quota Center console.
If no response is received from the backend server within the request timeout period, ALB returns the HTTP 504 error code to the client.
Compression
If you enable compression, specific types of files are compressed. If you disable compression, no file is compressed.
Brotli supports all file types.
GZIP supports the following file types:
text/xml,text/plain,text/css,application/javascript,application/x-javascript,application/rss+xml,application/atom+xml,application/xml, andapplication/json.
NoteOnly when the value of
Content-Lengthexceeds 1,024 bytes, data compression is triggered.If a client request allows both Brotli and GZIP compression, ALB will use Brotli compression.
If a client request allows only GZIP compression, and at least one file is in a format not supported by GZIP, ALB will not compress any files.
Retrieve Client IP
Specifies whether to enable ALB to retrieve the originating IP address of a client from the X-Forwarded-For header field. If you enable this feature, you must specify a trusted IP address list.
If you set the trusted IP address list to
0.0.0.0/0, the ALB instance retrieves the leftmost IP address in the X-Forwarded-For header. The IP address is the source client IP address.If you set the trusted IP address list in the format of
proxy1 IP;proxy2 IP;.., the ALB instance compares the IP addresses in the X-Forwarded-For header from right to left against the trusted IP address list. The first IP address that is not on the trusted IP address list is considered the source client IP address.
Scenarios:
If the X-Forwarded-For request header contains multiple IP addresses, such as
X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …, the leftmost address is the source client IP address. To use the SourceIp matching feature and the QPS (throttling Based On Client Source IP) feature in ALB forwarding rules, you must turn on the Retrieve Client IP switch to allow the ALB instance to retrieve the source client IP address from the X-Forwarded-For header. For more information, see Create a forwarding rule.NoteOnly Standard and WAF-enabled ALB instances support the Retrieve Client IP feature. Basic ALB instances do not support this feature.
Add HTTP Header
Select the HTTP headers that you want to add.
Choose whether to use the
X-Forwarded-Forheader to preserve the source IP address.If you select
Add X-Forwarded-For to preserve client IP addresses, ALB can add anX-Forwarded-Forheader to or remove theX-Forwarded-Forheader from the request before forwarding the request to a backend server.Add (default)
If you choose Add, ALB adds the IP address of the last hop to the X-Forwarded-For header in the request before forwarding the request to a backend server. If the request does not contain the X-Forwarded-For header, ALB creates an X-Forwarded-For header whose value is the IP address of the last hop and adds the header to the request. The X-Forwarded-For header in the request may contain multiple IP addresses which are separated by commas (,).
Remove
If you choose Remove, ALB removes the
X-Forwarded-Forheader from the request before forwarding the request to a backend server.
If you do not select
Add X-Forwarded-For to preserve client IP addresses, ALB does nothing about theX-Forwarded-Forheader in the request before forwarding the request to a backend server.
Format:
X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …Add SLB-ID to preserve SLB instance IDs: Add the SLB-ID header to store the ID of the ALB instance.Add X-Forwarded-Proto to preserve listener protocols: Add the X-Forwarded-Proto header to store the listener protocol.Add X-Forwarded-Port to preserve SLB listener ports: Add the X-Forwarded-Port header to store the listener port.Add X-Forwarded-Host to preserve client domain names: Add the X-Forwarded-Host header to store the domain name of the client.Add X-Forwarded-Client-srcport to preserve client ports: Add the X-Forwarded-Client-srcport header to store the client port.Add X-Forwarded-Clientcert-subjectdn to preserve owner information about client certificates: Add the X-Forwarded-Clientcert-subjectdn header to store the owner information about the client certificate.Add X-Forwarded-Clientcert-issuerdn to preserve information about client certificate issuers: Add the X-Forwarded-Clientcert-issuerdn header to store information about the authority that issues the client certificate.Add X-Forwarded-Clientcert-fingerprint to preserve client certificate fingerprints: Add the X-Forwarded-Clientcert-fingerprint header to store the fingerprint of the client certificate.Add X-Forwarded-Clientcert-clientverify to preserve client certificate verification results: Add the X-Forwarded-Clientcert-clientverify header to store the verification result of the client certificate.
NoteWe recommend that you configure your backend servers to follow the HTTP standard – be case-insensitive when processing the request headers.
The X-Forwarded-For header that is created and added to the request by ALB always starts with an uppercase "X."
Except for X-Forwarded-For, for the headers mentioned above, ALB processes them following the rules described above. For other headers, ALB keeps them in their original form in the request.
You cannot specify the custom header keys of X-Forwarded-Clientcert-subjectdn, X-Forwarded-Clientcert-issuerdn, X-Forwarded-Clientcert-fingerprint, and X-Forwarded-Clientcert-clientverify as follows:
slb-id,slb-ip,x-forwarded-for,x-forwarded-proto,x-forwarded-eip,x-forwarded-port,x-forwarded-client-srcport,x-forwarded-host,connection,upgrade,content-length,transfer-encoding,keep-alive,te,host,cookie,remoteip, andauthority
QUIC Update
Specify whether to enable Quick UDP Internet Connections (QUIC) upgrade. To use this feature, you must select a QUIC listener from the Associated QUIC Listeners drop-down list.
If no QUIC listener is created, click Create Listener to create one. For more information, see Add a QUIC listener.
ALB supports iQUIC and gQUIC. For more information, see Use QUIC to accelerate the delivery of video and audio content.
Step 2: Add an SSL certificate
To create an HTTPS listener, you must configure an SSL certificate for identity authentication to secure data transmission. The following table describes the certificates that are supported by ALB.
Certificate | Description | Required for one-way authentication | Required for mutual authentication |
Server certificate | A server certificate is used to authenticate the identity of a server. The client browser checks whether the certificate sent by the server is signed and issued by a trusted certificate authority (CA). For more information, see What is an SSL certificate? | Yes You can purchase or upload a server certificate in the Certificate Management Service console. ALB obtains the certificate from Certificate Management Service and uses the certificate. | Yes You can purchase or upload a server certificate in the Certificate Management Service console. ALB obtains the certificate from Certificate Management Service and uses the certificate. |
CA certificate | A CA certificate is used by a server to verify the signature on a client certificate. If the signature is invalid, the connection request is denied. Note A client certificate is used to authenticate the identity of the client when the client communicates with the server. You need to install a client certificate only on the client. | No | Yes. You can purchase or upload a CA certificate in the Certificate Management Service console. ALB obtains the certificate from Certificate Management Service and uses the certificate. |
It may take a few minutes to upload, load, and verify a new certificate. Therefore, an HTTPS listener is not available immediately after it is created. It requires about 1 to 3 minutes to enable an HTTPS listener.
If you want to access multiple domain names or add multiple server certificates, you can add additional certificates for the HTTPS listener.
In the Configure SSL Certificate step, select a server certificate.
(Optional) Turn on Enable Mutual Authentication and select a certificate source.
Select Alibaba Cloud as the source of the CA certificate, and select a CA certificate from the Default CA Certificate drop-down list.
If no CA certificate is available, you can click Purchase CA Certificate to create one.
Alternatively, select Third-party as the source of the CA certificate, and select a CA certificate from the Default CA Certificate drop-down list.
If no self-signed CA certificate is available, click Upload Self-signed CA Certificate in the drop-down list. On the Certificate Application Repository page, create a repository with Uploaded CA Certificates as Data Source. Then, upload self-signed root CA certificates or intermediate CA certificates to the repository.
Only standard and WAF-enabled ALB instances support mutual authentication. Basic ALB instances do not support mutual authentication.
If you want to disable mutual authentication after you enable this feature, perform the following operations:
On the Instances page, click the ID of the ALB instance that you want to manage.
On the Listener tab, click the ID of the HTTPS listener that you want to manage.
On the Listener Details tab, disable mutual authentication in the SSL Certificate section.
Select a TLS security policy and click Next.
If no TLS security policy is available, click Create TLS Security Policy to create one.
A TLS security policy contains TLS protocol versions and cipher suites that are available for HTTPS listeners.
Step 3: Select a server group
In the Server Group step, select a server group, view the backend servers, and then click Next.
Step 4: Review the configurations
In the Confirm step, confirm the configurations and click Submit.
Quick creation
If you select this method, you only need to specify a listener protocol, a listener port, a server certificate, a TLS security policy, and a server group.
Log on to the ALB console.
In the top navigation bar, select the region where the ALB instance resides.
On the Instances page, find the ALB instance that you want to manage and click its ID.
Click the Listener tab. On the Listener tab, click Quick Create Listener.
In the Quick Create Listener dialog box, configure the following parameters and click OK.
Parameter
Description
Listener Protocol
Select a listener protocol. In this example, HTTPS is selected.
Listener Port
The frontend port that is used to receive and forward requests to backend servers.
You can select a commonly used port, or enter a port number. Valid values: 1 to 65535.
Server Certificate
Select a server certificate from the drop-down list.
If no server certificate is available, click Create SSL Certificate to create one. For more information, see Purchase an SSL certificate and Upload an SSL certificate.
Resource Group
Select a resource group for the server group.
TLS Security Policy
If no TLS security policy is available, click Create TLS Security Policy to create one. For more information, see TLS security policies.
Server Group
Set the server group type and backend servers in the server group.
FAQ
What are the TLS versions supported by HTTPS listeners?
HTTPS listeners support TLS 1.0, 1.1, 1.2, and 1.3. For more information, see TLS security policies.
Can backend servers retrieve the TLS version used by the associated HTTPS listener?
Yes, backend servers can retrieve the TLS version used by the associated HTTPS listener.
Which HTTP version is used by HTTPS listeners to distribute network traffic to backend servers?
If client requests use HTTP/1.1 or HTTP/2, Layer 7 listeners use HTTP/1.1 to distribute network traffic to backend servers.
If client requests use protocols other than HTTP/1.1 and HTTP/2, Layer 7 listeners use HTTP/1.0 to distribute network traffic to backend servers.
What requirements does a wildcard listener certificate need to meet?
When you configure a wildcard certificate for an HTTPS listener, take note of the following limits:
When you select a wildcard certificate, ALB can identify certificates that contain only one wildcard (
*), which must be on the leftmost side of the domain name. For example, ALB can identify*.example.comand*test.example.com, but cannot identifytest*.example.com.Requirements for wildcard certificates:
Levels of wildcard domain names: A wildcard domain name can match specific domain names that are of the same level as the wildcard domain name. For example,
*.example.comcan matchtest.example.combut cannot matchtest.test.example.com, which is one level lower than the wildcard domain name.Internationalized domain names (IDNAs):
If the wildcard character is the only wildcard character and on the leftmost side of the wildcard domain name, IDNAs can match the wildcard domain name. For example,
xn--fsqu00a.example.comcan match*.example.com.If the wildcard character is not on the leftmost side of the wildcard domain name, IDNAs cannot match the wildcard domain name. For example,
xn--fsqu00atest.example.comcannot math*test.example.com.
Match scope: The wildcard character (
*) can match digits, letters, and hyphens (-). For example,*.example.comcan matchtest.example.combut cannot matchtest_test.example.com.
References
Learn more
ALB supports various advanced routing features. For more information, see Manage forwarding rules for a listener.
If you encounter any error code issues, refer to ALB status codes.
If any backend server is declared unhealthy, refer to Troubleshoot ALB health check issues.
HTTPS listeners are ideal for various use scenarios. For more information, see the following topics:
Redirect HTTP requests to an HTTPS listener: Configure forwarding rules for ALB listeners to redirect HTTP requests to HTTPS listeners. This encrypts data transmission on ALB instances, preventing man-in-the-middle attacks and data leakages, and helps you build a modern and secure network architecture.
Configure end-to-end HTTPS encryption for data transfers: ALB supports end-to-end HTTPS encryption for data transmission, encrypting data transmitted between clients and ALB, as well as between ALB and backend servers, to enhance the security of sensitive data.
Configure an ALB instance to serve multiple domain names over HTTPS: To forward HTTPS requests destined for various domain names to different backend servers, associate multiple certificates with an HTTPS listener and configure domain-based forwarding rules.
Configure mutual authentication on an HTTPS listener: For businesses requiring highly secure authentication, such as financial and medical scenarios, enable HTTPS mutual authentication for an ALB instance. This requires both the client and server to validate each other's identity, thereby improving the security of data transmission.