Docs

Volcengine Kubernetes Engine

Certificate and security

Configuring mutual authentication on HTTPS listeners for ALB Ingresses

An Application Load Balancer (ALB) Ingress supports mutual authentication, which ensures server and client security in HTTPS scenarios. This topic describes the scenarios and configuration methods of mutual authentication for ALB instances over HTTPS.

warning

It is highly recommended that you first read Considerations for using ALB Ingresses carefully before getting started.

Background information

In Internet communication security, the HTTPS protocol implements data encryption and identity authentication through the SSL/TLS layer. Common core authentication modes include one-way authentication and mutual (two-way) authentication. The following table describes the two modes.

Authentication method	Description	Authentication process
One-way authentication	It is a fundamental, client-initiated security authentication method. The core logic is that only the client verifies the identity of the server, while the server does not verify the identity of the client. The purpose is to ensure that the client accesses the legitimate server (not phishing or fraudulent sites) through the digital certificate mechanism.	The client initiates an HTTPS connection request to the server, explicitly specifying supported SSL/TLS versions and encryption algorithms. Upon receiving the request, the server sends its SSL certificate to the client (containing critical server data including the public key, domain information, certificate validity period, and the digital signature of the CA). The client performs multi-layer validation on the received certificate. It first checks certificate expiration status, then verifies certificate signature legitimacy using locally stored trusted CA root certificates, and confirms that the domain name in the certificate matches the domain of the server. If all validations pass, the client uses the public key in the certificate to negotiate a symmetric encryption key for subsequent data transmission with the server, establishing a secure connection.
Mutual authentication	It is a high-security mutual authentication method where the client and server verify each other. It extends the one-way authentication model by adding "server verification of client identity," forming a bidirectional trust mechanism: "client verifies server + server verifies client." It is designed for scenarios that require elevated security assurance.	The first three steps are the same as one-way authentication: the client initiates a request, the server sends a certificate, and the client successfully verifies the server certificate. Upon successful client verification, the server sends the client a ‌certificate request‌ to demand its SSL certificate. The client sends its ‌client certificate‌ containing identity information (such as the user ID, device serial number) to the server. The server verifies the client certificate using the same logic: It checks the validity period of the client certificate, validates cryptographic signature (requires trusting the client certificate's issuing CA), and performs business-rule validation (for example, confirms whether the certificate holder is an authorized enterprise employee or belongs to permitted device groups). If the client certificate verification passes, the server negotiates symmetric session keys to establish a mutually authenticated secure connection. If verification fails at any stage, the connection attempt immediately terminates.

tip

We recommend that you purchase and manage certificates by using Volcano Engine Certificate Center. If you have not yet purchased a certificate, you can follow the instructions below to generate a self-signed certificate.

Prerequisites

The clusters have been created. For details, see Creating clusters.

The cluster has been connected. For details, see Connecting to clusters.

The alb-ingress-controller add-on has been installed and upgraded to v0.32.0 or later. For details, see Upgrading add-ons.

You have purchased or obtained the server certificate and CA certificate, and uploaded them to the Certificate Center or ALB console. For details, see Uploading SSL certificates, Creating a private root CA, and Managing certificates.

Procedure

Step 1: Generate a certificate

Generate a self-signed CA certificate

Download OpenSSL from the OpenSSL website to your local environment and install it.

Execute the following command to generate a 4096-bit private key of the CA.

openssl genrsa -out ca.key 4096

Run the following command to generate the root CA certificate using the private key of the CA.

openssl req -new -x509 -key ca.key -out ca.crt

The expected response is that you need to provide information such as the country, region, organization name, domain, and email address.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:CN # A two-letter country code, for example, CN.
State or Province Name (full name) []:Shanghai # Region name, for example, Shanghai.
Locality Name (eg, city) []:Shanghai # City name, for example, Shanghai.
Organization Name (eg, company) []:vke # Organization name.
Organizational Unit Name (eg, section) []:vke # Organizational unit name.
Common Name (eg, fully qualified host name) []:example.com # Domain name of the certificate.
Email Address []:user@example.com # Email address.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:mypassword # Password (optional).

Complete the creation of the root CA certificate, including the private key ca.key and the certificateca.crt.

Generate a server certificate

Run the following command to generate a 2048-bit private key for the server.

openssl genrsa -out server.key 2048

Run the following command to use the private key of the server to generate a certificate request.

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

The expected response is that you need to provide information such as the country, region, organization name, domain, and email address.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:CN # A two-letter country code, for example, CN.
State or Province Name (full name) []:Shanghai # Region name, for example, Shanghai.
Locality Name (eg, city) []:Shanghai # City name, for example, Shanghai.
Organization Name (eg, company) []:vke # Organization name.
Organizational Unit Name (eg, section) []:vke # Organizational unit name.
Common Name (eg, fully qualified host name) []:example.com # Domain name of the certificate.
Email Address []:user@example.com # Email address.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:mypassword # Password (optional).

Run the following command to use the CA certificate to issue a server certificate, with the validity period set to 365 days.

openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

Finish creating the server certificate, including the private key server.key and certificate server.crt.

Generate a client certificate

Run the following command to generate a 2048-bit private key for the client.

openssl genrsa -out client.key 2048

Run the following command to generate a client certificate request using the private key of the client.

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

The expected response is that you need to provide information such as the country, region, organization name, domain, and email address.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:CN # A two-letter country code, for example, CN.
State or Province Name (full name) []:Shanghai # Region name, for example, Shanghai.
Locality Name (eg, city) []:Shanghai # City name, for example, Shanghai.
Organization Name (eg, company) []:vke # Organization name.
Organizational Unit Name (eg, section) []:vke # Organizational unit name.
Common Name (eg, fully qualified host name) []:example.com # Domain name of the certificate.
Email Address []:user@example.com # Email address.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:mypassword # Password (optional).

Run the following command to issue a client certificate using the CA certificate, with the validity period set to 365 days.

openssl x509 -req -in client.csr -out client.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

Complete the creation of the client certificate, including the private key client.key and the certificate client.crt.

Step 2: Upload certificates

In the ALB console, upload the certificates and keys. For details, see Managing certificates. After the certificates have been added, record the IDs of the certificates. The certificate IDs will be used in configuration later.

You can also purchase certificates from or upload certificates to Volcano Engine Certificate Center. For details, see Creating SSL certificates, Uploading SSL certificates, and Creating a private root CA. After purchasing or uploading your certificates, record their IDs, which will be used in the configuration later.

Step 3: Configure the ALBInstance

When you use an ALBInstance to associate with an existing ALB instance or create a new ALB instance, you can configure HTTPS mutual authentication by using fields caEnabled and caCertificates in spec.listeners. This section demonstrates how to associate with an existing ALB instance. The following is an example:

The following table describes subfields in the caEnabled and caCertificates fields of the spec.listeners.

Parameter	Type	Required	Description	Sample value	Editable
caEnabled	Boolean	None	The mutual authentication switch for HTTPS listeners. Valid values: true: Enable mutual authentication. false: Disable mutual authentication. tip If this field is not configured, the mutual authentication configuration of the ALB listener will not be modified.	true	Yes
caCertificateID	String	None	The ID of the certificate for mutual authentication. Description When caEnabled is true, this field must be configured.	cert-2wx20lm7uquww7oot********	Yes
caCertificateSource	String	None	The source of the certificate for mutual authentication. Valid values: alb (default): Certificates uploaded to ALB. pca_root: Private root CA certificates purchased from or uploaded to Volcano Engine Certificate Center. pca_sub: Private subordinate CA certificates purchased from or uploaded to Volcano Engine Certificate Center. warning When caEnabled is true, this field must be configured.	alb	Yes

tip

The caCertificates field can contain only a certificate source and certificate ID.

Step 4: Configure an ALB Ingress

Create an Ingress and choose an HTTPS listener. The following code provides an example:

tip

This example uses the simplest method to create an ALB Ingress. For more configuration details, see Creating ALB Ingresses by using kubectl.

Validating results

Viewing configuration

Run the following command to view the Ingress configuration.

kubectl get ingress

If the response is similar to the following one, the ALB Ingress has been created.

NAME CLASS HOSTS ADDRESS PORTS AGE
alb-ingress-demo alb example.com 180.xxx.xxx.xxx 80,443 74s

In the left navigation bar, select Instance. On the page that appears, click the name of the target ALB instance to go to the instance details page.

Click the Listener information tab. Click the name of the listener whose port is 443 to view the listener details. You can see that mutual authentication has been enabled for the listener.

Testing the connections to services

tip

Before verification, make sure that you have deployed backend applications and services in the cluster. This example uses the nginx image and the path /. For deployment steps, see Using ALB Ingresses for service deployment.

Run the following command to access the service by using the domain name.

curl -H "Host: example.com" https://180.xxx.xxx.xxx --insecure

The expected response is that the service is inaccessible because the request contains no client certificate for mutual authentication.

<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
</body>
</html>

Run the following command to access the service with the client certificate and key.

curl -H "Host: example.com" https://180.xxx.xxx.xxx --insecure --cert client.crt --key client.key

The expected response is that the service is accessible because the request contains a valid client certificate for mutual authentication.

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Last updated: 2026.07.24 14:51:38