One-way authentication, where only the client validates the identity of the server, cannot meet security requirements in financial transactions, medical, banking, and online payment scenarios. The server trusts any clients that connect to it, which incurs risks of man-in-the-middle attacks and unauthorized access. Application Load Balancer (ALB) enables mutual authentication on HTTPS listeners. Under mutual authentication, both the client and the server must validate each other's identities before they can establish a secure connection for data transmission.
Mutual authentication overview
Why mutual authentication is necessary
Most Internet web applications welcome diverse clients to access them. For these applications, only one-way HTTPS authentication is required: the client validates the server identity before interacting with the application, ensuring that it connects to a valid server.
However, in scenarios requiring higher level of security, not only the server identity is required to be verified, the client authentication is also needed. Mutual authentication is useful in this case. It ensures that only authorized clients can access the server, reducing security risks such as man-in-the-middle attacks and unauthorized access.
Use scenarios
For businesses with high security requirements, such as financial transactions, healthcare, banking, and online payments, not only the client side needs to verify the identity of the server, but the server must authenticate the client as well.
If there is no need for client authentication, mutual authentication is not required.
Limitations
Only Standard Edition and WAF-Enhanced Edition ALB instances support mutual authentication. Basic Edition ALB instances do not support this feature.
Only HTTPS listeners support mutual authentication. QUIC listeners and HTTP listeners do not support this feature.
Sample scenario
A company has deployed a customer-facing online transaction platform. Initially, they only used one-way HTTPS authentication for data transmission on this platform but discovered that some unauthorized devices were attempting to access the system, posing risks of data breaches and transaction tampering. Additionally, as the business grew, the platform faced increased performance challenges during traffic spikes.
To resolve these issues, the company decided to deploy Alibaba Cloud ALB and enable mutual authentication for the ALB service.
Through ALB's load balancing capability, client requests can be efficiently distributed to backend servers, ensuring stable performance and fast response times even in high concurrency scenarios.
By enabling mutual authentication on ALB, all clients accessing the platform must provide a valid client certificate to establish a connection with the platform, effectively blocking unauthorized devices from accessing the system and significantly reducing the risk of data breaches and transaction tampering.
Prerequisites
You have purchased or uploaded a server certificate to the Certificate Management Service.
In this example, a certificate is purchased.
NoteTo purchase an SSL certificate, you must have a valid custom domain name.
An intermediate CA certificate is purchased in the Certificate Management Service console, and at least one private intermediate CA certificate is available. Alternatively, a self-signed root CA certificate or intermediate CA certificate is uploaded to Certificate Management Service.
You have created a virtual private cloud (VPC) (named VPC1 in this guide), and created two Elastic Compute Service (ECS) instances in VPC1 (named ECS01 and ECS02, respectively in this guide), with applications deployed on both the ECS instances.
In this guide, the Alibaba Cloud Linux 3 operating system is used on the ECS instances and NGINX is used to configure HTTPS services.
A standard or WAF-enabled ALB instance is created.
You have created a server group and added ECS01 and ECS02 as backend servers to the server group.
If you want ALB to communicate with backend servers using the HTTPS protocol, select HTTPS as the backend protocol when creating the server group, and ensure that the backend servers have HTTPS services deployed.
Procedure
Step 1: Deploy client certificates
On the client (user) side, the client certificate must be ready and exported.
This guide introduces two ways to obtain CA certificates. You can purchase a CA certificate through the Certificate Management Service and apply for a client certificate, or you can upload a self-signed CA certificate to the Certificate Management Service.
1. Prepare the client certificate
Option 1: Apply for a client certificate
Refer to Apply for a private certificate to apply for a client certificate.
Log on to the Certificate Management Service console.
In the navigation pane on the left, choose . On the PCA Certificate Management page, select the region where the PCA service is located.
On the Private CAs tab, find the private intermediate CA that you want to use and click Apply for Certificate in the Actions column.

In the Apply for Certificate panel, configure the parameters and click Confirm. The following table describes the parameters.
In this guide, when applying for a client certificate, set Certificate Type to Client Certificate, and specify Personal Name (used as a unique identifier for the client user). Keep the default settings for other parameters when applying for a client certificate or modify them as needed.

After you submit a certificate application, the private certificate is immediately issued. Then, you can click Certificates in the Actions column to view the information about the private certificate.
Option 2: Upload a self-signed CA certificate
Log on to ECS01 remotely and use the following commands to generate a self-signed root CA certificate.
ALB supports self-signed root CA or self-signed intermediate CA certificates for mutual authentication. In this guide, a self-signed root CA certificate is used.
Use the following command to create a root CA certificate private key:
openssl genrsa -out root.key 4096Use the following command to create a file for requesting a root CA certificate:
openssl req -new -out root.csr -key root.keySet the other parameters. Example:
NoteEnsure that the common name in the CA certificate is different from those in the client certificate and the server certificate.
Country Name (2 letter code) [XX]:cn State or Province Name (full name) []:bj Locality Name (eg, city) [Default City]:bj Organization Name (eg, company) [Default Company Ltd]:alibaba Organizational Unit Name (eg, section) []:test Common Name (eg, your name or your servers hostname) []:root Email Address []:a****@example.com A challenge password []: An optional company name []:Use the following command to create a root CA certificate:
openssl x509 -req -in root.csr -out root.crt -signkey root.key -CAcreateserial -days 3650An example of the output:

Use the
lscommand to check the generated root CA certificateroot.crtand root CA certificate private keyroot.key.Download these root CA certificate files to your local computer so that you can upload them to the Certificate Management Service later.
Upload the self-signed root CA certificate to Certificate Management Service.
Log on to the Certificate Management Service.
In the navigation pane on the left, choose .
On the Certificate Application Repository page, click Create Repository. In the Create Repository panel, set Data Source to Uploaded CA Certificates, then click OK.

On the Certificate Application Repository page, click the created certificate repository.
On the Official Certificate page, click Uploaded Certificates. In the CA Information panel, upload the root CA certificate file
root.crt, and click Confirm and Enable.
2. Export the client certificate
Option 1: Export the client certificate purchased through the Certificate Management Service
If you have purchased a client certificate through the Certificate Management Service and want to use the client certificate for mutual authentication, perform the following operations to export the client certificate:
In the left-side navigation pane, choose PCA Certificate Management. On the Private CAs tab, find the private intermediate CA from which the required private certificate is issued and click Certificates in the Actions column.

On the Certificates page, find the private certificate that you want to download and click Download in the Actions column.
In the Download Certificate dialog box, set the Certificate Format parameter and click Confirm and Download. If you turn on Include Trust Chain, the certificate that is downloaded includes the complete certificate chain.
In this guide, set Certificate Format to PFX, which can be recognized by browsers.

As shown in the following figure, the downloaded certificate files include a client certificate file with a
.pfxextension and a client private key encryption password in a.txtfile.
Option 2: Export the client certificate generated from a self-signed certificate
If you have uploaded a self-signed CA certificate to the Certificate Management Service and need to use a client certificate generated from the self-signed CA certificate for mutual authentication, perform the following operations to generate a client certificate:
Log on to ECS01 remotely and perform the following steps to generate a client certificate.
Use the following command to generate a client certificate key:
openssl genrsa -out client.key 4096Use the following command to generate a file for requesting a client certificate:
openssl req -new -out client.csr -key client.keySet the other parameters. Example:
NoteEnsure that the common name in the CA certificate is different from the those in the server certificate, the root certificate, and other client certificates.
Country Name (2 letter code) [XX]:cn State or Province Name (full name) []:bj Locality Name (eg, city) [Default City]:bj Organization Name (eg, company) [Default Company Ltd]:alibaba Organizational Unit Name (eg, section) []:test Common Name (eg, your name or your servers hostname) []:client-alb-user Email Address []:username@example.com A challenge password []: An optional company name []:Use the following command to generate a client certificate.
openssl x509 -req -in client.csr -out client.crt -CA root.crt -CAkey root.key -CAcreateserial -days 3650An example of the output:

Use the following command to convert the generated client certificate
client.crtto a PKCS12 file that can be recognized by browsers. Follow the prompts to enter the client private key encryption password you set.openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12Use the
lscommand to check the generatedclient.p12client certificate file.Download the client certificate file to your local computer so that you can send it to the client later.
Step 2: Configure an HTTPS listener with mutual authentication enabled
In the top navigation bar of the ALB console, choose the region where your ALB instance is located. On the Instances page, find your ALB instance and click its ID.
On the instance details page, click the Listeners tab, click Create Listener, complete the following configuration, then click Next.
In this guide, set Listener Protocol to HTTPS, Listener Port to 443. Keep the default values for other HTTPS listener parameters or modify them as needed.

In the Configure SSL Certificate step, select the purchased server certificate. Turn on Enable Mutual Authentication, select a CA certificate source and a CA certificate. Select a TLS security policy and click Next.
If CA Certificate Source is set to Alibaba Cloud, select the CA certificate applied for in Step 1: Deploy client certificates from the Default CA Certificate drop-down list.
If CA Certificate Source is set to Third-party, select the self-signed CA certificate uploaded in Step 1: Deploy client certificates from the Default CA Certificate drop-down list.
The following figure shows an example of selecting an Alibaba Cloud-issued CA certificate.

In the Select Server Group step, select Server Type and the created server group from the drop-down list on the right. Check the information of backend servers ECS01 and ECS02, then click Next.
In the Configuration Review step, confirm the configuration information, then click Submit.
Step 3: Add a DNS record
For your business, we recommend that you add a DNS record to map your custom domain name to the domain name of your ALB instance.
In the left-side navigation pane of the ALB console, choose . On the Instances page, copy the DNS name of your ALB instance.
Add a CNAME record.
On the Authoritative DNS Resolution page, find your custom domain name, then in the Actions column, click DNS Settings.
NoteFor domain names not registered with Alibaba Cloud, you need to first add the domain name to Alibaba Cloud DNS before you can configure DNS resolution.
On the DNS Settings page, click Add DNS Record, configure the CNAME record, then click OK.
In this guide, set Record Type to CNAME and Record Value to the DNS name of your ALB instance. Keep the default values for other DNS record parameters or modify them as needed.

Step 4: Test the mutual authentication effect
In this guide, a Windows client and the Chrome browser on it is used for testing.
Install the exported client certificate on the client.
Double-click the downloaded client certificate file and follow the prompts of the system certificate import wizard to complete the installation.
Enter
https://<Your custom domain name>in the address field of the Chrome browser. In the dialog box that appears, select the certificate to use for client authentication.
Refresh the page multiple times. If responses from ECS01 and ECS02 are alternately returned, mutual authentication is implemented.


References
Console
Manage and use certificates in the ALB console:
Purchase CA-signed certificates and create self-signed certificates in the Certificate Management Service console:
API
Call the following API operations and set the CaEnabled parameter to true to enable mutual authentication: