If your application requires encrypted transmission, you can add an HTTPS listener to forward HTTPS requests. This feature enables traffic encryption between an Application Load Balancer (ALB) instance and clients that initiate SSL or TLS sessions.
Prerequisites
You have created an Application Load Balancer (ALB) instance.
You have deployed a TLS security policy and at least one server certificate on the ALB instance.
You have created an available server group.
Procedure
This topic describes two methods for adding an HTTPS listener. You can choose a method based on your business requirements.
Create an HTTPS listener: You can customize advanced features, such as mutual authentication.
Quickly create an HTTPS listener: You can quickly create a listener by configuring only the listener protocol, listener port, server certificate, TLS security policy, and server group.
Create an HTTPS listener
Step 1: Configure the listener
Log on to the Application Load Balancer (ALB) console.
In the top navigation bar, select the region where the instance is deployed.
Use one of the following methods to open the listener configuration wizard:
On the Instances page, find the target instance and click Create Listener in the Actions column.
On the Instances page, click the ID of the target instance. On the Listener tab, click Create Listener.
On the Configure Listener page, set the following parameters and click Next.
Parameter
Description
Listener Protocol
Select a protocol for the listener.
This example selects HTTPS.
Listener Port
Specify the port to receive and forward requests to backend servers. This example uses port 443. Port 80 is typically used for HTTP and port 443 is used for HTTPS.
The valid port range is 1 to 65535.
NoteOn the same ALB instance, the ports of listeners that use the same protocol must be unique. HTTP listeners and HTTPS listeners must use different ports.
Listener Name
Enter a name for the listener.
Tag
Set a Tag Key and Tag Value.
After you add a tag, you can filter listeners by tag on the Listener tab.
Advanced Settings
Click Modify to expand the advanced settings.
Enable HTTP/2
Select whether to enable HTTP/2.
Idle Connection Timeout Period
Specify the idle timeout. Valid values: 1 to 600 seconds. The default value is 15 seconds. To request a quota increase, go to Quota Center.
If no request is received within the idle timeout, the load balancer closes the connection. It establishes a new connection when the next request is received.
Connection Request Timeout
Specify the request timeout. Valid values: 1 to 600 seconds. The default value is 60 seconds. To request a quota increase, go to Quota Center.
If a backend server does not respond within the timeout period, the load balancer stops waiting and returns an HTTP 504 error to the client.
Compression
If you enable this feature, specific types of files are compressed. If you disable this feature, no files are compressed.
Brotli supports compressing 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.
NoteData compression is triggered only when the value of the
Content-Lengthheader in the response exceeds 1,024 bytes.If a client request supports both Brotli and Gzip compression algorithms, ALB prioritizes Brotli due to its higher efficiency.
If a client supports only the Gzip compression algorithm and the file type is not supported by Gzip, ALB does not compress the file.
Retrieve Client IP
Enables ALB to retrieve the source IP address from the X-Forwarded-For header. If you enable this feature, you must configure a trusted IP list.
If the trusted IP list is set to
0.0.0.0/0, ALB retrieves the leftmost IP address from the X-Forwarded-For request header as the source IP address.If the trusted IP list is set to
proxy1 IP;proxy2 IP;.., ALB retrieves the first IP address from right to left that is not in the list and uses it as the source IP address.
Use cases:
When 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 client's source IP address. If you use forwarding rules based on SourceIp matching or the QPS (Per Client IP) feature in ALB, you must enable Retrieve Client IP. This allows ALB to find the source IP address from the X-Forwarded-For header. For more information, see Add forwarding rules.NoteOnly Standard and WAF-enabled ALB instances support retrieving the source IP address. Basic ALB instances do not.
Add HTTP Header
Select the custom HTTP header field to add:
Select whether to enable the
X-Forwarded-Forheader field to get the client 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 the
SLB-IDheader field to get the ID of the load balancer instance.Add the
X-Forwarded-Protoheader field to get the listener protocol of the instance.Add the
X-Forwarded-Portheader field to get the listener port of the load balancer instance.Add the
X-Forwarded-Hostheader field to get the domain name used by the client to access the load balancer instance.Add the
X-Forwarded-Client-srcportheader field to get the port of the client that accesses the load balancer instance.Add the
X-Forwarded-Clientcert-subjectdnheader field to get the owner information of the client certificate used to access the load balancer instance.Add the
X-Forwarded-Clientcert-issuerdnheader field to get the issuer information of the client certificate used to access the load balancer instance.Add the
X-Forwarded-Clientcert-fingerprintheader field to get the fingerprint of the client certificate used to access the load balancer instance.Add the
X-Forwarded-Clientcert-clientverifyheader field to get the verification result of the client certificate used to access the load balancer instance.
NoteYour backend server should follow HTTP protocol specifications and treat HTTP header field keys as case-insensitive.
ALB always capitalizes the first letter of the X-Forwarded-For additional header field when passing it to a backend server.
For other additional HTTP header fields, if a client request includes a specific header field, ALB passes it to the backend server in the same format as in the client request. Otherwise, ALB passes the header field to the backend server in the format specified for the field name in the table above.
When X-Forwarded-Clientcert-subjectdn, X-Forwarded-Clientcert-issuerdn, X-Forwarded-Clientcert-fingerprint, and X-Forwarded-Clientcert-clientverify are enabled, do not set custom HTTP header names to any of the following fields:
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, orauthority.
QUIC Update
Select whether to enable QUIC upgrade. If you enable this feature, select an existing QUIC listener from the Associated QUIC Listeners drop-down list.
If you have not created a QUIC listener, click Create Listener to create one. For more information, see Add a QUIC listener.
ALB supports iQUIC and gQUIC. For a tutorial, see Use the QUIC protocol to accelerate audio and video streaming.
Step 2: Configure an SSL certificate
To add an HTTPS listener, you must configure an SSL certificate to encrypt traffic and validate your service's identity. The following table describes the certificates that ALB supports.
Certificate | Description | One-way authentication | Mutual authentication |
Server certificate | Proves the server's identity. Your browser checks if a trusted authority issued the server's certificate. For more information, see What is an SSL certificate?. | Yes You can purchase or upload a server certificate in Certificate Management Service. ALB obtains and uses the certificate from Certificate Management Service. | Yes You can purchase or upload a server certificate in Certificate Management Service. ALB obtains and uses the certificate from Certificate Management Service. |
CA certificate | The server uses a CA certificate to verify the client certificate's signature. The connection is rejected if verification fails. Note When a client communicates with a server, a client certificate is used to prove the client's identity. The client certificate needs to be installed only on the client. | No | Yes You can purchase or upload a CA certificate in Certificate Management Service. ALB obtains and uses the certificate from Certificate Management Service. |
Applying a new certificate to an HTTPS listener can take one to three minutes to take effect because of the time required for uploading, loading, and verification.
If you need to handle multiple domain names or attach multiple server certificates, you can add an extension certificate for the HTTPS listener after it is configured.
In the SSL Certificate step, select a server certificate.
Optional: Turn on Enable Mutual Authentication, and select the source of the CA certificate.
Select Alibaba Cloud as the CA certificate source, and select a CA certificate from the Default CA Certificate drop-down list.
If no CA certificate is available, click Purchase CA Certificate in the drop-down list to create a new CA certificate.
Select Third-party as the CA certificate source, 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 the data source. Then, upload a self-signed root CA or a self-signed intermediate CA certificate to the repository.
NoteOnly Standard and WAF-enabled ALB instances support mutual authentication. Basic ALB instances do not.
After you enable mutual authentication, if you need to disable it later, follow these steps:
On the Instances page, click the ID of the target instance.
On the Listener tab, click the ID of the target HTTPS listener.
On the Listener Details tab, turn off the mutual authentication switch 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 in the drop-down list.
A TLS security policy includes the supported TLS protocol versions and cipher suites for HTTPS.
Step 3: Select a server group
In the Server Group step of the wizard, select a server group, view the backend server information, and then click Next.
Step 4: Review configuration
On the Confirm page, review the configuration and click Submit.
Quick create an HTTPS listener
If you use the quick creation method, you only need to configure the listener protocol, listener port, server certificate, TLS security policy, and server group.
Log on to the Application Load Balancer (ALB) console.
In the top navigation bar, select the region where the ALB instance is deployed.
On the Instances page, find the target instance and click its ID.
Click the Listener tab, and 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. This example selects HTTPS.
Listener Port
Set the frontend port that is used to receive requests and forward them to backend servers.
You can click a common listener port to quickly fill in the value, or enter a port number. The valid port range is 1 to 65535.
Server Certificate
Select a server certificate from the drop-down list.
If no server certificate is available, click Create Certificate in the drop-down list to create a new certificate. For more information, see Purchase an SSL certificate and Upload an SSL certificate.
Resource Group
Select the resource group to which the server group belongs.
TLS Security Policy
If no TLS security policy is available, click Create TLS Security Policy in the drop-down list. For more information, see TLS security policies.
Server Group
Select the server group type and backend servers.
FAQ
Supported TLS versions
Listeners support TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. For more information, see TLS security policies.
Retrieving the client protocol version
Yes.
HTTP version for backend access
If a client request uses HTTP 1.1 or HTTP 2.0, the Layer 7 listener uses HTTP 1.1 to access the backend server.
If a client request uses a protocol other than HTTP 1.1 or HTTP 2.0, the Layer 7 listener uses HTTP 1.0 to access the backend server.
Wildcard certificate rules
When you add an HTTPS listener to an ALB instance, if the selected certificate is a wildcard certificate, note the following rules.
When you select a wildcard certificate, ALB can identify only certificates that contain a single wildcard character (
*) and that place the wildcard character (*) at the far left of the domain name. For example, ALB can identify*.example.comand*test.example.com, but cannot identifytest*.example.com.Wildcard domain name matching rules:
Wildcard level: A wildcard domain name can match only subdomains of the same level. For example,
*.example.comcan matchtest.example.com, but cannot matchtest.test.example.combecause the subdomain and the wildcard domain name are at different levels.IDNA support:
If the wildcard character in the wildcard certificate is the only character in the leftmost label, an IDNA label can match the wildcard character. For example,
xn--fsqu00a.example.comcan match*.example.com.If the wildcard character in the wildcard certificate is not the only character in the leftmost label, an IDNA label cannot match that part of the wildcard. For example,
xn--fsqu00atest.example.comcannot match*test.example.com.
Character support: The wildcard character (
*) in a wildcard certificate can match only digits 0–9, uppercase and lowercase letters, and hyphens (-). For example,*.example.comcan matchtest.example.com, but cannot matchtest_test.example.com.
What is the TTL of an HTTPS session ticket?
300 seconds.
How can I prevent X-Forwarded-For header spoofing?
Specify a header field from another upstream product to record the real client IP:
For example, in a Client -> CDN -> WAF -> SLB > ECS architecture: CDN forwards the client's real IP in the
Ali-Cdn-Real-IpHTTP header. When configuring WAF, set the client IP detection method to "Specify Header Field" and useAli-Cdn-Real-Ip. Subsequently, on the backend Nginx server, configure the log variable for the real client IP to be$http_Ali_Cdn_Real_Ip.Switch to a layer 4 listener (NLB or CLB): When using a layer 4 listener, backend servers can automatically obtain the real client IP. For details, see Enable Layer 4 listeners to preserve client IP addresses and pass them to backend servers.
WSS support
By default, ALB HTTPS listeners support the WebSocket Secure (WSS) protocol. For a tutorial, see Use WebSocket to enable real-time messaging.
References
Product tutorials
ALB supports a wide range of advanced forwarding rules. For more information, see Configure listener forwarding rules.
If you encounter an abnormal status code, see ALB error status codes.
If you encounter a health check issue, see Troubleshoot ALB health check issues.
For more use case tutorials, see the following topics:
Redirect HTTP requests to an HTTPS listener: You can use ALB forwarding rules to redirect HTTP requests to HTTPS listeners. This encrypts data in transit, prevents man-in-the-middle attacks and data breaches, and helps you build a modern and secure network architecture.
Configure end-to-end HTTPS access for encrypted communication: ALB provides end-to-end HTTPS encryption, which secures communication from client to ALB and from ALB to backend server, enhancing security for sensitive services.
Configure a single ALB instance for multiple HTTPS websites: When you need to forward HTTPS requests for different domains to different backend servers, you can bind multiple certificates to an ALB HTTPS listener and configure domain-based forwarding rules to handle access for multiple HTTPS websites.
Deploy an HTTPS service with ALB (mutual authentication): For scenarios that require high-security verification, such as finance and healthcare, ALB's mutual authentication feature provides identity verification for both clients and servers, ensuring secure data transfer.