Manage certificates-Server Load Balancer(SLB)-阿里云帮助中心

To enable encrypted transmission using a TCP/SSL listener, configure certificates on NLB. All NLB certificates are stored and managed by Alibaba Cloud Certificate Management Service. Purchase a certificate or upload an existing one to Certificate Management Service before using it on NLB.

How it works

Certificate types

CA certificate: A certification authority (CA) is a trusted third party that verifies and issues certificates. CA certificates validate the legitimacy of other certificates—for example, by checking whether a certificate was issued by a trusted CA.
Server certificate: Also known as an SSL Certificate, this is issued by a CA and contains the server’s public key and identity information (such as its domain name). It proves the server’s identity to clients.
Client certificate: Issued by a CA, this contains the client’s public key and identity information. It proves the client’s identity to the server.

What are root CA, intermediate CA, and certificate chain?

The root CA is the highest level in the certificate hierarchy. Its certificate is the starting point of the entire trust chain. Root CA certificates are typically self-signed and pre-trusted by operating systems, browsers, and applications to verify the legitimacy of other certificates (such as intermediate CA and end-entity certificates). In practice, root CAs rarely issue end-entity certificates (like server or client certificates) directly. Instead, they issue intermediate CA certificates.

An intermediate CA sits between the root CA and end-entity certificates. Its certificate is signed by the root CA and used to issue server certificates, client certificates, and other end-entity certificates. Using intermediate CAs keeps the root CA’s private key secure while extending the scope of trust.

When verifying each other’s certificates, clients and servers follow the certificate chain, validating signatures step by step from the presented certificate up to a root CA certificate they trust.

For example, if the certificate chain is server certificate → intermediate CA certificate → root CA certificate, the client checks:

Was the server certificate issued by the intermediate CA?
Was the intermediate CA certificate issued by the root CA?
Is the root CA certificate in the client’s trust list?

The server is trusted only if all checks pass. If the server does not provide a complete certificate chain (for example, missing the intermediate CA certificate), the client reports the certificate as untrusted.

Authentication modes

NLB supports both one-way and mutual authentication.

One-way authentication: NLB requires only a server certificate. The client verifies the server’s identity. This is the most common mode, suitable for most web applications and API services.
Mutual authentication: NLB requires both a server certificate and a CA certificate. The server and client authenticate each other. This mode is used in high-security scenarios such as finance, Internet of Things (IoT), and internal enterprise systems.

One-way authentication handshake process	Mutual authentication handshake process

Prerequisites

Prepare the required certificates based on your authentication mode (one-way or mutual). To purchase certificates from Alibaba Cloud, see:

CA certificate: Purchase and enable a private CA
Server certificate: Purchase a commercial certificate
Client certificate: Download a private certificate

Configure certificates for one-way authentication

Console

When configuring a TCP/SSL listener, on the Configure SSL Certificate page, select a server certificate and configure the TLS security policy.

For a step-by-step tutorial, see: Offload TCP/SSL with NLB (one-way authentication).

API

Call the CreateListener operation:

Set the ListenerProtocol field to TCPSSL to create a TCP/SSL listener.
Configure the server certificate in the CertificateIds field.
Configure the TLS security policy in the SecurityPolicyId field.

Configure certificates for mutual authentication

Console

When configuring a TCP/SSL listener, on the Configure SSL Certificate page, select a server certificate, enable mutual authentication, and configure a CA certificate. Also configure the TLS security policy.

For a step-by-step tutorial, see: Offload TCP/SSL with NLB (mutual authentication).

API

Call the CreateListener operation:

Set the ListenerProtocol field to TCPSSL to create a TCP/SSL listener.
Configure the server certificate in the CertificateIds field.
Set the CaEnabled field to true to enable mutual authentication.
Configure the CA certificate in the CaCertificateIds field.
Configure the TLS security policy in the SecurityPolicyId field.

Switch between one-way and mutual authentication

For an existing TCP/SSL listener, you can enable or disable mutual authentication to switch between one-way and mutual authentication.

Console

In the NLB console, find your NLB instance and click its instance ID.
On the Listener tab, find your TCP/SSL listener and click Actions → Manage Certificates.
On the CA Certificate tab, toggle the Mutual Authentication switch in the upper-left corner to enable or disable mutual authentication. Select a CA certificate and click OK.

API

Call the UpdateListenerAttribute operation. Use the ListenerId field to select your TCP/SSL listener. Set the CaEnabled field to enable or disable mutual authentication. Update the CaCertificateIds field to select a CA certificate.

Manage server certificates

Replace the default server certificate

The server certificate selected when configuring a TCP/SSL listener becomes the listener’s default server certificate. Replace it seamlessly when the certificate is about to expire or when business requirements change.

New connections may be interrupted during the default server certificate update. Existing connections remain unaffected. Perform this change during off-peak hours.

Console

In the NLB console, find your NLB instance and click its instance ID.
On the Listener tab, find your TCP/SSL listener and click Actions → Manage Certificates.
On the Server Certificate tab, click Default Server Certificate → Change, then select a new certificate.
Click OK.

API

Call the UpdateListenerAttribute operation. Use the ListenerId field to select your TCP/SSL listener. Update the CertificateIds field to replace the default server certificate.

Configure extended certificates for multiple domains

If a single listening port must serve HTTPS traffic for multiple domains, each with its own certificate, use NLB’s extended certificate feature.

After configuration, NLB automatically selects the correct certificate based on the domain in the client’s request.

If the requested domain matches an extended certificate, NLB uses that certificate.
If no match is found, NLB uses the default server certificate.

1. Each NLB instance supports up to 25 extended certificates.

2. You can add or remove up to 15 extended certificates in a single operation.

Console

In the NLB console, find your NLB instance and click its instance ID.
On the Listener tab, find your TCP/SSL listener and click Actions → Manage Certificates.
On the Server Certificate tab, click Add Additional Certificate and select certificates for additional domains.
Click OK.

To delete an extended certificate, click Actions → Delete next to the certificate.

API

Call the AssociateAdditionalCertificatesWithListener operation. Use the ListenerId field to select your TCP/SSL listener. Add extended certificates using the AdditionalCertificateIds field.
Call the DisassociateAdditionalCertificatesWithListener operation. Use the ListenerId field to select your TCP/SSL listener. Remove extended certificates using the AdditionalCertificateIds field.

Manage CA certificates

Replace a CA certificate

Console

In the NLB console, find your NLB instance and click its instance ID.
On the Listener tab, find your TCP/SSL listener and click Actions → Manage Certificates.
On the CA Certificate tab, if mutual authentication is enabled, click Actions → Change next to the CA certificate. Select a new CA certificate and click OK.

API

Call the UpdateListenerAttribute operation. Use the ListenerId field to select your TCP/SSL listener. Update the CaCertificateIds field to replace the CA certificate.

Billing details

Using the certificate feature with TCP/SSL listeners incurs no extra charges. However, you must pay for the certificates themselves. For details, see: SSL Certificate billing details, PCA certificate billing details.

Going live

Best practices
- Certificate management: Use Alibaba Cloud Certificate Management Service to centrally manage all certificates. This simplifies viewing, renewal, and deployment.
- TLS policy: For public-facing applications without special compatibility requirements, use tls_cipher_policy_1_2 or higher.
- Automation: Combine APIs or Terraform with Certificate Management Service to automate certificate renewal and deployment. This prevents service interruptions caused by expired certificates.
Risk mitigation and fault tolerance
- Internal traffic security: Traffic between clients and NLB is encrypted with TCP/SSL, but traffic between NLB and backend servers is plaintext by default. To ensure end-to-end security, deploy NLB and backend servers in the same VPC and restrict access strictly using security groups.
- Certificate expiration monitoring: Configure expiration alert rules for certificates in Cloud Monitor. Set alerts at 30 days, 7 days, and 1 day before expiration to allow enough time for replacement.
- Rollback: If issues occur after replacing a certificate or changing the TLS policy, immediately roll back by updating the listener configuration. Perform changes during off-peak hours.