If your application requires encrypted data transmission, you can create an HTTPS listener to forward HTTPS requests. HTTPS listeners provide end-to-end encryption for traffic between clients and Application Load Balancer (ALB) instances.
Prerequisites
You have created an ALB instance.
You have deployed a TLS security policy and at least one SSL server certificate on the ALB instance.
Procedures
This topic describes two methods for creating an HTTPS listener. Choose one based on your needs.
Create an HTTPS listener: Customize advanced features such as mutual authentication.
Quickly create an HTTPS listener: Quickly create a listener by configuring only the listener protocol, listener port, server certificate, TLS security policy, and backend 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 located.
Use one of the following methods to open the listener configuration wizard.
On the Instances page, find the target instance and click Actions in the Create Listener column.
On the Instances page, click the target instance ID. On the Listener tab, click Create Listener.
On the Configure Listener wizard, complete the following settings and click Next.
Listener Configuration
Description
Listener Protocol
Select the listener protocol type.
In this example, select HTTPS.
Listener Port
Enter the port that receives requests and forwards them to backend servers. In this example, enter 443. Typically, HTTP uses port 80 and HTTPS uses port 443.
Valid values: 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 tags, you can filter listeners by tag on the Listeners tab.
Advanced Settings
Click Modify to expand advanced settings.
Enable HTTP/2
Choose whether to enable HTTP/2.
Idle Connection Timeout Period
Specify the idle connection timeout in seconds. Valid values: 1 to 600. Default: 15 seconds. To increase this quota, go to the Quota Center.
If no request arrives within the timeout period, the load balancer closes the current connection and establishes a new one when the next request arrives.
Connection Request Timeout
Specify the request timeout in seconds. Valid values: 1 to 600. Default: 60 seconds. To increase this quota, go to the Quota Center.
If the backend server does not respond within the timeout period, the load balancer stops waiting and returns an HTTP 504 error to the client.
Data Compression
When enabled, specific file types are compressed. When disabled, no files are compressed.
Brotli compresses all file types.
Gzip compresses the following types:
text/xml,text/plain,text/css,application/javascript,application/x-javascript,application/rss+xml,application/atom+xml,application/xml, andapplication/json.
NoteData compression triggers only when the response
Content-Lengthexceeds 1,024 bytes.If a client request supports both Brotli and Gzip, ALB uses Brotli because it is more efficient.
If a client request supports only Gzip and includes a file type not supported by Gzip, ALB does not compress any files.
Retrieve Client IP
Specify whether to enable the ALB instance to retrieve client IP addresses from the X-Forwarded-For header. If you enable this feature, you must specify trusted IP addresses.
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.
Usage notes
If the X-Forwarded-For header contains multiple IP addresses, such as
X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …, the leftmost IP address is the source client IP address. If you want to enable the matching based on source IP addresses and throttling based on QPS per client IP address features in ALB forwarding rules, you must turn on the Retrieve Client IP switch to allow the ALB instance to retrieve source client IP addresses from the X-Forwarded-For header. For more information, see Add Forwarding Rules.NoteRetrieve Client IP is supported only by standard and WAF-enabled ALB instances, but not by basic ALB instances.
Additional HTTP Header Fields
Select custom HTTP headers to add:
Choose whether to enable the
X-Forwarded-Forheader to obtain 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 SLB instance ID.Add the
X-Forwarded-Protoheader field to get the instance's listener protocol.Add the
X-Forwarded-Portheader field to get the Server Load Balancer instance's listening port.Add the
X-Forwarded-Hostheader field to obtain the domain name of the client accessing the SLB instance.Add the
X-Forwarded-Client-srcportheader field to get the port of the client that accesses the Server Load Balancer instance.Add the
X-Forwarded-Clientcert-subjectdnheader field to get the owner information from the client certificate that accesses the SLB instance.Add the
X-Forwarded-Clientcert-issuerdnheader field to retrieve the issuer information of the client certificate that is used to access the SLB instance.Add the
X-Forwarded-Clientcert-fingerprintheader field to obtain the fingerprint value of the client certificate accessing the Server Load Balancer instance.Add the
X-Forwarded-Clientcert-clientverifyheader to store the client certificate verification result.
NoteYour backend servers must follow the HTTP protocol specification when reading HTTP header fields. Header field names are case-insensitive.
ALB always sends the X-Forwarded-For header field with the first letter capitalized.
For other custom HTTP headers, ALB forwards them to your backend servers using the same case as in the client request—if the client includes the header. Otherwise, ALB uses the case shown in the preceding table.
When you enable X-Forwarded-Clientcert-subjectdn, X-Forwarded-Clientcert-issuerdn, X-Forwarded-Clientcert-fingerprint, or X-Forwarded-Clientcert-clientverify, do not use any of the following names for custom HTTP headers:
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
Specify whether to enable QUIC upgrade. If enabled, select a created QUIC listener from the Associated QUIC listeners drop-down list.
If no QUIC listener exists, 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: Configure SSL Certificates
When you add an HTTPS listener, you must configure an SSL certificate to encrypt traffic and authenticate your service with a trusted authority. The following table describes the certificates that ALB supports.
Certificate | Description | Required for one-way authentication | Required for mutual authentication |
Server certificate | Verifies the identity of the server. Your 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 it. | 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 it. |
CA certificate | The server uses a CA certificate to verify the client certificate's signature. If validation fails, the connection is rejected. Note A client certificate authenticates the client's identity to the server. Client certificates must be installed only on the client. | No. | Yes. You can purchase or upload a CA certificate in the Certificate Management Service console. ALB obtains this certificate from Certificate Management Service and uses it. |
Uploading, loading, and validating new certificates takes time. After you apply a new certificate, the HTTPS listener takes time to become effective. This process usually takes one minute but can take up to three minutes.
To support multiple domain names or attach multiple server certificates, you can add extension certificates after you configure the listener. For more information, see add extension certificates.
In the SSL Certificate wizard, you can select a server certificate.
Optional: Enable Mutual Authentication, and then select the certificate source.
Select Alibaba Cloud Issued as the certificate source. From the Select Default CA Certificate drop-down list, select a CA certificate.
If no CA certificates are available, you can click Purchase CA Certificate in the drop-down list to create a new CA certificate. For more information, see the referenced document.
Select Third-party Issued as the certificate source. From the Select Default CA Certificate drop-down list, select a CA certificate.
If a self-signed CA certificate is not available, you can click Upload Self-Signed CA Certificate from the drop-down list, create a repository on the Certificate Application Repository page and set the data source to Upload CA Certificate, and then upload a self-signed root or sub-root CA certificate.
NoteOnly standard and WAF-enabled ALB instances support mutual authentication. Basic ALB instances do not support mutual authentication.
If you enable mutual authentication and want to disable it later, follow these steps:
On the Instances page, click the target instance ID.
On the Listener tab, click the ID of the target HTTPS listener.
On the Listener Details tab, in the SSL Certificate section, disable mutual authentication.
Select a TLS security policy, then click Next.
If no TLS security policy is available, you can click Create TLS Security Policy to create one.
A TLS security policy defines the TLS protocol versions and cipher suites that are available for an HTTPS listener.
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
On the Confirm page, confirm the configurations and click Submit.
Quickly create an HTTPS listener
The quick creation feature lets you create a listener by configuring only the listener protocol, listening port, server certificate, TLS security policy, and backend server group.
Log on to the Application Load Balancer (ALB) console.
In the top navigation bar, select the region where the ALB instance is located.
On the Instances page, find the target instance and click its instance 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.
Listener Configuration
Description
Listener Protocol
Select a listener protocol. This example uses HTTPS.
Listener Port
The listening port is the frontend port that receives requests and forwards them to backend servers.
Select a common port or enter a port number from 1 to 65535.
Server Certificate
Select a server certificate from the drop-down list.
If no server certificate is available, click Create Certificate to create one. For more information, see Purchase a commercial certificate and Upload an SSL Certificate.
Select Resource Group
Select a resource group for the backend 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
Select the type of backend server group and the backend servers.
FAQ
How to prevent X-Forwarded-For field forgery?
TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. For more information, see TLS security policy.
Can backend servers retrieve the TLS version used by the associated HTTPS listener?
Yes.
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 add an HTTPS listener to an ALB instance, note the following rules if you select a wildcard certificate.
When you select a wildcard certificate, ALB recognizes only wildcard certificates that contain a single wildcard character
*. The wildcard character*must be at the beginning of the domain name. For example, ALB can recognize*.example.comand*test.example.com, but cannot recognizetest*.example.com.Wildcard domain name matching rules:
Wildcard level: A wildcard domain name matches only subdomains at the same level. For example,
*.example.comcan matchtest.example.com, but cannot matchtest.test.example.combecause the subdomain is not at the same level as the wildcard domain name.IDNA support:
If the wildcard character is the only character in the leftmost label of the wildcard certificate, an Internationalized Domain Name in Applications (IDNA) label can match the wildcard character. For example,
xn--fsqu00a.example.comcan match*.example.com.If the wildcard character is not the only character in the leftmost label of the wildcard certificate, 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 matches 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?
The TTL of an HTTPS session ticket is 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.
Does ALB support the WebSocket Secure (WSS) protocol?
ALB HTTPS listeners support the WebSocket Secure (WSS) protocol by default. For tutorials, see ALB uses the WebSocket protocol for real-time messaging.
References
Tutorials
ALB supports various advanced routing features. For more information, see Configure Listener Forwarding Rules.
If you encounter an error, see ALB error status codes.
If a backend server is declared unhealthy, see Troubleshoot ALB health check issues.
For more scenario-based tutorials, see the following resources:
Use ALB to redirect HTTP access to HTTPS: You can use ALB listener forwarding rules to redirect HTTP requests to HTTPS. This ensures encryption of data in-transit, prevents man-in-the-middle attacks and data breaches, and helps you build a network architecture that complies with modern security standards.
Configure end-to-end HTTPS encryption for data transfers: ALB supports end-to-end HTTPS encryption. This encrypts data transmitted between clients and ALB, and 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 applications that require highly secure authentication, such as in the finance and healthcare industries, you can enable HTTPS mutual authentication for an ALB instance. This requires both the client and the server to validate each other's identity, which improves the security of data transmission.