If your application requires encrypted data transfer, you can create an HTTPS listener to forward requests that use the HTTPS protocol. This listener encrypts traffic between an Application Load Balancer (ALB) instance and clients that initiate SSL or TLS sessions.
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.
You have created a backend server group.
Procedure
This topic describes two methods for creating an HTTPS listener. You can choose a method based on your needs.
Create an HTTPS listener: This method lets you customize advanced features, such as mutual authentication.
Quickly create an HTTPS listener: This method lets you 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 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.
In the Configure Listener wizard, set the following parameters and click Next.
Listener Configuration
Description
Listener Protocol
Select a protocol for the listener.
In this example, HTTPS is selected.
Listener Port
Enter the listener port that is used to receive requests and forward them to backend servers. In this example, 443 is entered. Port 80 is the default port for HTTP and port 443 is the default port for HTTPS.
The port number must be between 1 and 65535.
NoteWithin the same ALB instance, listeners of the same protocol cannot use the same port. HTTP and HTTPS listeners cannot use the same port.
Listener Name
Enter a name for the listener.
Tag
Set Tag Key and Tag Value.
After you set tags, you can filter listeners by tag on the Listener tab.
Advanced Settings
Click Modify to expand Advanced Configuration.
Enable HTTP/2
Select whether to enable HTTP/2.
Idle Connection Timeout Period
Specify the idle timeout period. Valid values: 1 to 600 seconds. Default value: 15 seconds. If you want to use a larger value, go to Quota Center to request a quota increase.
If no request is received within the timeout period, Server Load Balancer temporarily breaks the current connection. A new connection is established when the next request is received.
NoteThis feature does not take effect for HTTP/2 requests.
Connection Request Timeout
Specify the request timeout period. Valid values: 1 to 600 seconds. Default value: 60 seconds. If you want to use a larger value, go to Quota Center to request a quota increase.
If no response is received from the backend server within the timeout period, Server Load Balancer gives up and returns an HTTP 504 error code to the client.
Data Compression
Enable this feature to compress specific file types. If this feature is disabled, no files are 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
.
NoteData compression is triggered only when the
Content-Length
of the response exceeds 1024 bytes.If a client request supports both Brotli and Gzip, ALB uses Brotli, which is more efficient.
If a client supports only Gzip and the file type is not supported by Gzip, ALB does not compress the file.
Retrieve Client IP
Enable this feature to allow ALB to retrieve the originating client IP address from the X-Forwarded-For header field. After you enable this feature, you must configure a list of trusted IP addresses.
If you set the list of trusted IP addresses to
0.0.0.0/0
: Retrieves the leftmost IP address from the X-Forwarded-For request header as the originating client IP address.If you set the list of trusted IP addresses to
proxy1 IP;proxy2 IP;..
: Retrieves the first IP address from the right that is not in this list as the originating client IP address.
Scenarios:
The X-Forwarded-For request header can contain multiple IP addresses, such as
X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …
. The leftmost address is the client's IP address. To use the SourceIp matching condition and the QPS (throttling Based On Client Source IP) feature in ALB forwarding rules, enable Find Originating Client IP Address. This allows ALB to find the originating client IP address from the X-Forwarded-For header field. For more information, see Add forwarding rules.NoteOnly Standard and WAF-enabled ALB instances support this feature. Basic ALB instances do not.
Add HTTP Header Fields
Select the custom HTTP header fields that you want to add:
Select whether to enable the
X-Forwarded-For
header field to obtain the IP address of the client.If you select
Add X-Forwarded-For to preserve client IP addresses
, ALB can add anX-Forwarded-For
header to or remove theX-Forwarded-For
header 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-For
header 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-For
header in the request before forwarding the request to a backend server.
Format:
X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …
Add the
SLB-ID
header field to obtain the ID of the SLB instance.Add the
X-Forwarded-Proto
header field to obtain the listener protocol of the instance.Add the
X-Forwarded-Port
header field to obtain the listener port of the SLB instance.Add the
X-Forwarded-Host
header field to obtain the domain name used by the client to access the SLB instance.Add the
X-Forwarded-Client-srcport
header field to obtain the port of the client that accesses the SLB instance.Add the
X-Forwarded-Clientcert-subjectdn
header field to obtain the owner information of the client certificate used to access the SLB instance.Add the
X-Forwarded-Clientcert-issuerdn
header field to obtain the issuer information of the client certificate used to access the SLB instance.Add the
X-Forwarded-Clientcert-fingerprint
header field to obtain the fingerprint of the client certificate used to access the SLB instance.Add the
X-Forwarded-Clientcert-clientverify
header field to obtain the verification result of the client certificate used to access the SLB instance.
NoteWhen your backend server obtains HTTP header fields, we recommend that you follow HTTP protocol specifications and ignore the case of the keys in HTTP header fields.
The first letter of the X-Forwarded-For header field that ALB passes to the backend server is always uppercase.
For other added HTTP header fields, if a client request carries a specific header field, ALB passes it to the backend server in the format of the header field in the client request. Otherwise, ALB passes the header field to the backend server in the format shown in the preceding table.
When you enable X-Forwarded-Clientcert-subjectdn, X-Forwarded-Clientcert-issuerdn, X-Forwarded-Clientcert-fingerprint, and X-Forwarded-Clientcert-clientverify, you cannot set the custom HTTP header name 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 QUIC upgrade, select a created QUIC listener from the Associated QUIC Listener 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 more information, see Use the QUIC protocol to accelerate access to audio and video services.
Step 2: Configure SSL certificates
When you create an HTTPS listener, you must configure SSL certificates to ensure that your services are encrypted and authenticated by a certificate authority (CA). The following table describes the certificates that you can configure for ALB.
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 issued by a trusted CA. For more information, see What is an SSL certificate?. | Yes, it is. You can purchase or upload a server certificate in Certificate Management Service. ALB retrieves and uses the certificate from Certificate Management Service. | Yes, it is. You can purchase or upload a server certificate in Certificate Management Service. ALB retrieves and uses the certificate from Certificate Management Service. |
CA Certificate | The server uses the CA certificate to verify the signature of the client certificate. If the verification fails, the connection is rejected. Note A client certificate is used to prove the identity of the client when communicating with a server. This certificate is installed only on the client. | No, it is not. | Yes, it is. You can purchase or upload a CA certificate in Certificate Management Service. ALB retrieves and uses the certificate from Certificate Management Service. |
The upload, loading, and verification of a new certificate require some time. After a new certificate is applied to an instance that uses HTTPS, the certificate takes some time to take effect. The effective period is typically one minute and does not exceed three minutes.
To access multiple domain names or attach multiple server certificates, you can add an extension certificate to the HTTPS listener after it is configured.
In the SSL Certificate wizard, select a server certificate.
Optional: Turn on Enable Mutual Authentication and select a source for the CA certificate.
Set CA Certificate Source to Issued By Alibaba Cloud and select a CA certificate from the Select Default CA Certificate drop-down list.
If no CA certificates are available, click Purchase CA Certificate in the drop-down list to create a new CA certificate.
Set CA Certificate Source to Not Issued By Alibaba Cloud and select a CA certificate from the Select Default CA Certificate drop-down list.
If no self-signed CA certificates are available, click Upload Self-signed CA Certificate in the drop-down list. On the Certificate Application Repository page, create a repository and set its data source to Upload CA Certificate. Then, upload a self-signed root CA certificate or a self-signed intermediate CA certificate from the repository.
NoteOnly Standard and WAF-enabled ALB instances support mutual authentication. Basic ALB instances do not.
If you enable mutual authentication and later need to disable it, perform the following 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 policies are available, click Create TLS Security Policy in the drop-down list.
A TLS security policy contains the supported TLS protocol versions and cipher suites for HTTPS.
Step 3: Select a server group
In the Server Group wizard, select a server group, view the information about the backend servers, and then click Next.
Step 4: Review
On the Confirm page, review the configurations and click Submit.
Quickly create an HTTPS listener
If you choose to quickly create a listener, you need to configure only the listener protocol, listener 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 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, set the following parameters and click OK.
Listener Configuration
Description
Select Listener Protocol
Select a listener protocol. In this example, HTTPS is selected.
Listener Port
Specify the listener port. This is the frontend port that receives requests and forwards them to backend servers.
You can click a common port for quick selection or enter a custom port number. The valid port range is 1 to 65535.
Select Server Certificate
Select a server certificate from the drop-down list.
If no server certificates are available, click Create Certificate in the drop-down list to create a new one. For more information, see Purchase a commercial certificate and Upload an SSL certificate.
Select Resource Group
Select the resource group that contains the server group.
TLS Security Policy
If no TLS security policies are available, click Create TLS Security Policy in the drop-down list to create one. For more information, see TLS security policies.
Server Group
Select the server group type and the backend servers.
FAQ
What TLS protocol versions does HTTPS support?
TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. For more information, see TLS security policies.
Can a backend server get the protocol version of a client request to an HTTPS listener?
Yes, it can.
What is the HTTP protocol version that an HTTPS listener uses to access a backend server?
If the client request uses HTTP/1.1 or HTTP/2, the Layer 7 listener uses HTTP/1.1 to access the backend server.
If the client request uses a protocol other than HTTP/1.1 or HTTP/2, the Layer 7 listener uses HTTP/1.0 to access the backend server.
What are the rules for using a wildcard certificate for an ALB listener?
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.com
and*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.com
can matchtest.example.com
but 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.com
can 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.com
cannot math*test.example.com
.
Match scope: The wildcard character (
*
) can match digits, letters, and hyphens (-). For example,*.example.com
can matchtest.example.com
but cannot matchtest_test.example.com
.
What is the timeout period for an HTTPS session ticket?
The timeout period for an HTTPS session ticket is 300 seconds.
References
Tutorials
ALB provides a variety of advanced forwarding rules. For more information, see Configure listener forwarding rules.
If an abnormal status code is returned, see ALB status codes.
If a health check is abnormal, see Troubleshoot ALB health check exceptions.
For more scenario-based tutorials, 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 to implement encrypted communication: ALB provides end-to-end HTTPS encryption. This feature enables encrypted communication from clients to ALB and from ALB to backend servers, enhancing the security of sensitive services.
Configure multiple HTTPS websites for different domain names on a single ALB instance: To forward HTTPS requests for different domain names to different backend servers, you can attach multiple certificates to an ALB HTTPS listener and configure domain-based forwarding rules to enable access to multiple HTTPS websites.
Use ALB to deploy an HTTPS service (mutual authentication): In scenarios that require high security verification, such as finance and healthcare, you can use the HTTPS mutual authentication feature of ALB to implement mutual identity authentication between clients and servers. This ensures the security of data transfer.