HTTPS Mutual Authentication-Server Load Balancer(SLB)-阿里云帮助中心

Enable mutual authentication on ALB to require both the client and server to verify each other's identity before establishing a connection. This prevents man-in-the-middle attacks and unauthorized access in high-security scenarios such as financial transactions and healthcare.

Feature overview

Why use mutual authentication

Most web applications use one-way authentication to establish HTTPS connections. The client verifies the server's identity, ensuring it connects to the correct server.

For applications that require higher security, the server must also verify the client's identity. Mutual authentication ensures that only authorized clients can access the service, reducing risks such as man-in-the-middle attacks and unauthorized access.

Comparison of one-way and mutual authentication

Item

One-way authentication

Mutual authentication

Certificate files

Server certificate:

Server public key certificate
Server private key file

Server certificate:
- Server public key certificate
- Server private key file
Client certificate:
- Client public key certificate
- Client private key file
root CA certificate

Handshake process

Use cases

Financial transactions, healthcare, banking, and online payments — any scenario where the system must verify client identity in addition to the server.

If you do not need to authenticate clients, you do not need to use mutual authentication.

Limitations

Only Standard 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 and HTTP listeners do not support this feature.

Example scenario

An enterprise deployed an online transaction platform that initially used only one-way HTTPS authentication. Unauthorized devices were attempting to access the system, posing risks of data leakage and transaction tampering. As traffic grew, the platform also faced increasing performance pressure during peaks.

To address these issues, the enterprise deployed an ALB instance and enabled mutual authentication.

ALB distributes client requests across backend servers, ensuring stable performance and fast response times even during high-concurrency peaks.
With mutual authentication enabled, all clients must provide a valid certificate to establish a connection, preventing unauthorized access and reducing the risk of data leakage and transaction tampering.

Prerequisites

You have purchased or uploaded a server certificate in Certificate Management Service.
This topic uses a server certificate purchased from the Alibaba Cloud Certificate Management Service console as an example.
Note
When you purchase an SSL certificate, you must bind it to a domain name. Make sure you have a valid and accessible domain name.
For mutual authentication, you also need a CA certificate. You can purchase and enable a subordinate CA certificate (requires available certificate quota) or upload a self-signed root CA or subordinate CA certificate.
You have created a VPC (VPC1), and created two ECS instances (ECS01 and ECS02) in VPC1. Application services are deployed on both instances.
This example uses Alibaba Cloud Linux 3 as the operating system and Nginx to configure the HTTPS service.
Example commands for deploying a test service on ECS01
1. Run the following commands to install Nginx and deploy an example test application.
```
yum install -y nginx
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS01." > index.html
```
2. To allow the ALB instance to communicate with backend servers over HTTPS, you must upload the server certificate file to the backend server. Then, in the Nginx configuration file nginx.conf, configure the HTTPS service module, specify the certificate file path, and then save the file.
```
vim /etc/nginx/nginx.conf
```
  The following code provides an example:
```
http {
    ...
    # Existing configuration
    
    # HTTPS service module
    server {
      listen       443 ssl;
      server_name  _;
      root         /usr/share/nginx/html;

        # Replace with the path to your server certificate file.
        ssl_certificate "/etc/pki/nginx/server.crt";
        # Replace with the path to your server certificate private key file.
        ssl_certificate_key "/etc/pki/nginx/private/server.key";
        
        ...
    }
}
```
3. Run the following command to restart the Nginx service.
```
systemctl restart nginx.service
```
You have created an ALB instance of the Standard or WAF-enabled Edition.
You have created a server group and added ECS01 and ECS02 as backend servers.
If you want the ALB instance to communicate with backend servers over HTTPS, select HTTPS as the backend protocol when you create the server group and make sure that the HTTPS service is deployed on the backend servers.

Procedure

Step 1: Configure the client certificate

You must prepare and export a client certificate.

This topic describes two methods to obtain a CA certificate. You can purchase a CA certificate and apply for a client certificate in Certificate Management Service, or upload a self-signed CA certificate to Certificate Management Service.

1. Prepare a client certificate

From the console

For more information, see Apply for a private certificate.

Log in to the Certificate Management Service console.
In the navigation pane on the left, choose Certificate Management > Private Certificate Management. On the Private Certificate Management page, select the region where the PCA service is located.
On the Private CAs tab, find the target subordinate private CA and click Apply for Certificate in the Actions column.
In the Apply for Certificate panel, configure the certificate settings as described in the table below, and then click Confirm.
In this example, when you apply for a client certificate, set Certificate Type to Client Certificate and enter a Personal Name to uniquely identify the client user. You can keep the default values for other parameters or modify them as needed.
After submitting the application, the private certificate is issued immediately. Then, click Certificates in the Actions column for the subordinate private CA to view details of the issued certificate.

Self-signed

Log on to ECS01 and run the following commands to generate a self-signed root CA certificate.
An ALB instance supports mutual authentication using either a self-signed root CA certificate or a self-signed intermediate CA certificate. This example uses a self-signed root CA certificate.
1. Run the following command to create a private key for the root CA certificate:
```
openssl genrsa -out root.key 4096
```
2. Run the following command to create a certificate signing request (CSR) for the root CA certificate:
```
openssl req -new -out root.csr -key root.key
```
  Enter the required information as prompted. The following code provides an example:
  Note
  Make sure that the Common Name for the CA certificate is unique and not the same as the Common Name for the server certificate or the client 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 []:
```
3. Run the following command to create the root CA certificate:
```
openssl x509 -req -in root.csr -out root.crt -signkey root.key -CAcreateserial -days 3650
```
  The following output is returned:
```
Signature ok
subject=C = cn, ST = bj, L = bj, O = alibaba, OU = test, CN = root, emailAddress = a****@example.com
Getting Private Key
```
4. Run the ls command to view the generated root CA certificate root.crt and its private key root.key.
  You can download these root CA certificate files to your computer for later use.
Upload the self-signed root CA certificate to Certificate Management Service.
1. Log in to the Certificate Management Service console.
2. In the navigation pane on the left, choose Certificate Service > Certificate Application Repository.
3. On the Certificate Application Repository page, click Create Repository. In the Create repository panel, set Data source to Uploaded CA certificates and click OK.
4. On the Certificate Application Repository page, click the repository that you created.
5. On the Certificates page, click Uploaded Certificate. In the CA information panel, upload the root CA certificate file root.crt and click Confirm and Enable.

2. Export the client certificate

Export from console

To use a client certificate purchased from the console for mutual authentication, export it by following these steps:

On the Private CAs tab, find the target subordinate CA, and then click Certificates in the Actions column.
On the Certificates page, find the target private certificate, and then click Download in the Actions column.
In the Download Certificate dialog box, select the certificate format that you want to download, and then click Confirm and Download. If you select Include Trust Chain, the downloaded certificate includes the complete certificate chain.
In this example, select PFX for Certificate format. This format is recognizable by browsers.
The downloaded files include a client certificate file with the .pfx extension and a text file with the .txt extension that contains the encryption password for the client private key.

Export self-signed

To use a client certificate generated from a self-signed CA certificate for mutual authentication, follow these steps to generate it:

Log on to ECS01 and perform the following steps to generate a client certificate:

Run the following command to generate a private key for the client certificate:
```
openssl genrsa -out client.key 4096
```

Run the following command to generate a CSR for the client certificate:

openssl req -new -out client.csr -key client.key

Enter the required information as prompted. The following code provides an example:

Note

Make sure that the Common Name for the client certificate is unique and not the same as the Common Name for the server certificate, root certificate, or any other client 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) []:client-alb-user
Email Address []:username@example.com
A challenge password []:
An optional company name []:

Run the following command to generate the client certificate.

openssl x509 -req -in client.csr -out client.crt -CA root.crt -CAkey root.key -CAcreateserial -days 3650

The following output is returned:

Signature ok
subject=C = cn, ST = bj, L = bj, O = alibaba, OU = test, CN = client-alb-user, emailAddress = username@example.com
Getting CA Private Key

Run the following command to convert the generated client certificate client.crt to a PKCS12 file, which is recognizable by browsers. Enter the client private key encryption password as prompted.
```
openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12
```
Run the ls command to view the generated client.p12 client certificate file.
You can download the client certificate file to your computer for later use on the client.

Step 2: Configure a mutual authentication listener

In the top navigation bar of the ALB console, select the region where the ALB instance is deployed. On the Instances page, find the ALB instance that you want to manage and click its ID.
On the instance details page, click the Listener tab and click Create Listener. Configure the parameters and click Next.
In this example, set Select Listener Protocol to HTTPS and Listener Port to 443. You can keep the default values for other HTTPS listener parameters or modify them as needed.
In the SSL Certificate step, select the server certificate that you purchased. Then, turn on Enable Mutual Authentication and select a CA certificate source and its corresponding certificate. Finally, select a TLS security policy and click Next.
- Set CA Certificate Source to Alibaba Cloud. In the Default CA Certificate drop-down list, select the CA certificate that you applied for in Step 1: Configure the client certificate.
- Set CA Certificate Source to Third-party. In the Default CA Certificate drop-down list, select the self-signed CA certificate that you uploaded in Step 1: Configure the client certificate.
In the Server Group step, select a Server Type and the backend Server Type. Review the information about the backend servers ECS01 and ECS02, and then click Next.
In the Confirm step, review the configurations and click Submit.

Step 3: Configure DNS resolution

For production environments, we recommend that you create a CNAME record to map your custom domain name to the DNS name of the ALB instance.

In the left-side navigation pane of the ALB console, choose ALB > Instances. On the Instances page, copy the DNS name of the created ALB instance.
Perform the following steps to add a CNAME record.
1. On the DNS Resolution page, find the target custom domain name and click DNS Settings in the Operations column.
  Note
  If your domain name is not registered with Alibaba Cloud, you must first add your domain name to the Alibaba Cloud DNS console before you can configure DNS settings.
2. On the DNS settings page, click Add DNS record, configure the CNAME record, and click OK.
  In this example, set Record type to CNAME and Record value to the DNS name of the ALB instance. You can keep the default values for other DNS record parameters or modify them as needed.

Step 4: Test the mutual authentication

This example uses a Windows client and the Chrome browser.

Install the exported client certificate on the client.
Double-click the downloaded client certificate file and follow the prompts in the certificate import wizard to install the client certificate.
In the browser, enter https://<your custom domain name>. In the dialog box that appears, select the certificate to use for client authentication.
Refresh the browser. You can observe that client requests are distributed between the ECS01 and ECS02 servers.
If the page returns Hello World ! This is ECS01., the request is forwarded to ECS01.
If you refresh the page and it returns Hello World ! This is ECS02., the request is forwarded to ECS02.

References

Console operations

ALB-related information:
- Manage certificates
- Add an HTTPS listener
Certificate-related information:
- Purchase an SSL certificate
- What is Private Certificate Authority (PCA)?

API reference

You can call the following API operations and set the CaEnabled parameter to true to enable mutual authentication.