Updated on 2026-06-16 GMT+08:00

Configuring SNI for a LoadBalancer Service

An SNI certificate is an extended server certificate that allows the same IP address and port number to provide multiple access domain names for external systems. Different security certificates can be used based on the domain names requested by clients to ensure HTTPS communication security.

When configuring SNI, you need to add a certificate associated with a domain name. The client submits the requested domain name information when initiating an SSL handshake request. After receiving the SSL request, the load balancer searches for the certificate based on the domain name. If the certificate is found, the load balancer will return it to the client. If the certificate is not found, the load balancer will return the default server certificate.

After SNI is configured, if you delete the SNI configuration on the CCE console or delete the target annotation from the YAML file, the configuration on the ELB will be retained.

Prerequisites

  • A Kubernetes cluster is available and the cluster version meets the following requirements:
    • v1.23: v1.23.13-r0 or later
    • v1.25: v1.25.8-r0 or later
    • v1.27: v1.27.5-r0 or later
    • v1.28: v1.28.3-r0 or later
    • Other clusters of later versions

Step 1: Deploy a Sample Application

This section uses a Nginx Deployment as an example.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Workloads. In the upper right corner, click Create Workload.
  3. In the Basic Info area, enter the workload name. In this example, the workload name is nginx. Retain the default settings for other parameters.
  4. In Container Information under Container Settings, specify the image name and tag. Retain the default settings for other parameters.

    Parameter

    Example

    Image Name

    Click Select Image. In the displayed dialog box, click Open Source Images under SWR Shared Edition, search for nginx, select it, and click OK.

    Image Tag

    Select the latest image tag.

  5. Retain the default settings for other parameters and click Create Workload.

Step 2: Create a LoadBalancer Service and Configure SNI

Use one of the following methods.

This section uses the certificates cert-test and cert-sni-test as an example, where cert-sni-test includes an SNI domain name. Replace these certificates as needed.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Services & Ingresses. In the upper right corner, click Create Service.

    In this example, only mandatory parameters for configuring SNI are listed. Retain the default settings for other parameters. For details, see Using the CCE Console (New Version).

  3. Configure basic parameters.

    Parameter

    Description

    Example

    Service Type

    Select LoadBalancer.

    None

    Service Name

    Enter a name, which can be the same as the workload name.

    nginx

    Namespace

    Select the namespace that the workload belongs to.

    default

    Selector

    Add the key and value of a pod label. The Service will be associated with the workload pods based on the label and direct traffic to the pods with this label.

    You can also click Reference Workload Label to use the label of an existing workload. In the dialog box displayed, select a workload and click OK.

    app:nginx

  4. Configure load balancer parameters.

    Parameter

    Description

    Example

    Load Balancer

    Select a load balance type and how the load balancer will be created. To enable HTTP/HTTPS on the listener port of a dedicated load balancer, the type of the load balancer must be Application (HTTP/HTTPS) or Network (TCP/UDP/TLS) & Application (HTTP/HTTPS).
    • Use existing: Only the load balancers in the same VPC as the cluster can be selected. If no load balancer is available, click Create Load Balancer to create one on the ELB console.
    • Auto create: The load balancer will be created in the VPC that the cluster belongs to. For details, see Table 1.

    An existing Dedicated load balancer of the Network (TCP/UDP/TLS) & Application (HTTP/HTTPS) type

  5. Configure access parameters.

    Parameter

    Description

    Example

    Service Affinity

    Whether to route external traffic to a local node or a cluster-wide endpoint. For details, see Service Affinity (externalTrafficPolicy).
    • Cluster-level: The IP addresses and ports of all nodes in a cluster can access the workload associated with the Service. However, accessing the Service may result in performance deterioration due to route redirection, and the client's source IP address may not be obtainable.
    • Node-level: Only the IP address and port of the node where the workload is located can access the workload associated with the Service. Accessing the Service will not result in a performance deterioration due to route redirection, and the client's source IP address can be obtained.

    Cluster-level

    Backend Routing Policy

    • Global: All ports use the same backend routing policy. For details about the parameters, see Table 1.
      CAUTION:

      When multiple ports are added, and some of them use different frontend protocols, the global backend routing policy cannot be applied across all protocols simultaneously. For any protocol to which the policy cannot be applied, CCE automatically falls back to the default configuration. For details about the mapping between the frontend and backend protocols of listeners and backend server groups, see Mapping Between Frontend and Backend Protocols for Load Balancing and Configuration Examples. Custom is recommended.

    • Custom: Each port can have a unique backend routing policy. You can configure the policy in Port > Backend Routing Policy.

    Custom

    Port

    • Protocol: the protocol used by the Service. If a Service needs to use ELB TLS or HTTP, set Protocol to TCP and select the target frontend protocol. For details, see Protocols for Services.
    • Container Port: the port that the workload listens on. For example, Nginx uses port 80 by default.
    • Service Port: the port used by the Service.
      • Listen on a port: The port ranges from 1 to 65535.
      • Listen on ports: ELB allows you to create listeners that listen on ports within specified ranges. Each listener can support up to 10 non-overlapping port ranges.

        To configure port ranges for load balancer listeners, ensure the following conditions are met:

        • The cluster version must be v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0, v1.30.1-r0, or later.
        • A dedicated load balancer must be used with TCP/UDP/TLS selected.
        • This function requires ELB. Before using this function, check whether ELB supports full-port listening and forwarding for layer-4 protocols in the current region.
    • Frontend Protocol: Set the protocol of the load balancer listener for establishing connections with clients. When a dedicated load balancer is selected, HTTP/HTTPS can be configured only when Application (HTTP/HTTPS) is selected and TLS can be configured only when Network (TCP/UDP/TLS) is selected.
    • Backend Routing Policy: If Backend Routing Policy is set to Custom, you can configure backend routing policies for ports that use different protocols. For details about the parameters, see Table 1.
    NOTE:

    When a LoadBalancer Service is created, a random node port number (NodePort) is automatically generated.

    • Protocol: TCP
    • Container Port: 80
    • Service Port: 443
    • Frontend Protocol: HTTPS
    Table 1 Parameters for configuring the backend routing policy

    Parameter

    Description

    Example

    Backend Protocol

    The service protocol used by the load balancer's backend server group. TCP, HTTP, HTTPS, TLS, QUIC, and UDP are supported. For details about the mapping between the frontend and backend protocols of listeners and backend server groups, see Mapping Between Frontend and Backend Protocols for Load Balancing and Configuration Examples.

    HTTP

    Load Balancing Algorithm

    Load balancers forward requests from clients to the corresponding backend servers based on the configured traffic routing policies.

    • Weighted round robin: Requests are forwarded to different backend servers in turn based on the server weights you define in the target group.
    • Weighted least connections: Requests are forwarded to the backend server with the smallest connections-to-weight ratio.
    • Source IP hash: Requests from the same source IP address are forwarded to the same backend server by hashing the source IP address.

    Weighted round robin

  6. Configure listener HTTP/HTTPS and SNI parameters.

    Parameter

    Description

    Constraint

    Example

    SSL Authentication

    • One-way authentication: Only the backend server is authenticated. If you also need to authenticate the identity of the client, select two-way authentication.
    • Two-way authentication: Both the clients and the load balancer authenticate each other. This ensures only authenticated clients can access the load balancer. No additional backend server configuration is required if you select this option.

    This parameter is available only when Frontend Protocol is set to HTTPS or TLS.

    Dedicated load balancers are available in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later. Shared load balancers are available in clusters v1.28.15-r60, v1.29.15-r20, v1.30.14-r20, v1.31.10-r20, v1.32.6-r20, v1.33.5-r10, or later.

    One-way authentication

    CA Certificate

    If SSL Authentication is set to Two-way authentication, add a CA certificate to authenticate the client. A CA certificate is issued by a Certificate Authority (CA) and is used to verify the issuer of the client's certificate. If HTTPS two-way authentication is enabled, HTTPS connections can be established only if the client provides a certificate issued by a specific CA.

    This parameter is available only when Frontend Protocol is set to HTTPS or TLS and SSL Authentication is set to Two-way authentication.

    None

    Server Certificate

    Select a server certificate. If no certificate is available, create one on the ELB console. For details, see Adding a Certificate.

    This parameter is available only when Frontend Protocol is set to HTTPS or TLS.

    cert-test

    SNI

    Determine whether to add an SNI certificate. If an SNI certificate is required, the certificate must contain a domain name. If no certificate is available, create one on the ELB console. For details, see Adding a Certificate.

    If the server cannot find an SNI certificate matching the client-requested domain name, it will return the default server certificate.

    This parameter is available only when Frontend Protocol is set to HTTPS or TLS.

    cert-sni-test

  7. Configure a backend routing policy.

    Parameter

    Description

    Constraint

    Example Value

    Backend Protocol

    Protocol used by the load balancer to forward requests to backend servers. Backend servers must listen on this protocol and respond to requests.

    If Frontend Protocol is set to HTTPS, the backend protocol can be HTTP or HTTPS. The default value is HTTP.

    NOTE:

    When multiple ports are added, if the frontend protocols of some ports are not HTTPS, this configuration takes effect only for HTTPS ports.

    This parameter is only available in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later.

    HTTP

  8. Click Create.
  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Services & Ingresses. In the upper right corner, click Create Service.
  3. Configure Service parameters. In this example, only mandatory parameters required for using SNI are listed. For details about how to configure other parameters, see Using the CCE Console (Old Version).

    • Service Name: Specify a Service name, which can be the same as the workload name.
    • Service Type: Select LoadBalancer.
    • Selector: Add a label and click Confirm. The Service will use this label to select pods. You can also click Reference Workload Label to use the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
    • Load Balancer: Select a load balancer type and creation mode.
      • A load balancer can be dedicated or shared. To enable HTTP/HTTPS on the listener port of a dedicated load balancer, the type of the load balancer must be Application (HTTP/HTTPS) or Network (TCP/UDP) & Application (HTTP/HTTPS).
      • This section uses an existing load balancer as an example. For details about the parameters for automatically creating a load balancer, see Table 4.
    • Port
      • Protocol: Select TCP. If you select UDP, HTTP and HTTPS will be unavailable.
      • Service Port: the port used by the Service. The port ranges from 1 to 65535.
      • Container Port: the port that the workload listens on. For example, Nginx uses port 80 by default.
      • Frontend Protocol: In this example, HTTPS must be enabled for the Service to use SNI. For a dedicated load balancer, to use HTTP/HTTPS, the type of the load balancer must be Application (HTTP/HTTPS).
    • Listener
      • SSL Authentication: Select this option if Frontend Protocol is set to HTTPS. Dedicated load balancers are available in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later. Shared load balancers are available in clusters v1.28.15-r60, v1.29.15-r20, v1.30.14-r20, v1.31.10-r20, v1.32.6-r20, v1.33.5-r10, or later.
        • One-way authentication: Only the backend server is authenticated. If you also need to authenticate the identity of the client, select two-way authentication.
        • Two-way authentication: Both the clients and the load balancer authenticate each other. This ensures only authenticated clients can access the load balancer. No additional backend server configuration is required if you select this option.
      • CA Certificate: If SSL Authentication is set to Two-way authentication, add a CA certificate to authenticate the client. A CA certificate is issued by a Certificate Authority (CA) and is used to verify the issuer of the client's certificate. If HTTPS two-way authentication is enabled, HTTPS connections can be established only if the client provides a certificate issued by a specific CA.
      • Server Certificate: Select a server certificate as the default certificate. If no certificate is available, create one on the ELB console. For details, see Adding a Certificate.
      • SNI: Add an SNI certificate containing a domain name. If no certificate is available, create one on the ELB console. For details, see Adding a Certificate.

        If the server cannot find an SNI certificate matching the client-requested domain name, it will return the default server certificate.

      • Security Policy: If Frontend Protocol is set to HTTPS, you can select a security policy. This parameter is available only in clusters of v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later.
      • Backend Protocol: If Frontend Protocol is set to HTTPS, HTTP or HTTPS can be used to access the backend server. The default value is HTTP. This parameter is available only in clusters of v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later.
    Figure 1 SNI

  4. Click OK.
This section uses an existing load balancer as an example. An example YAML file of a SNI-compliant Service is as follows:
apiVersion: v1
kind: Service
metadata:
  name: test
  labels:
    app: test
  namespace: default
  annotations:
    kubernetes.io/elb.class: performance        # Load balancer type
    kubernetes.io/elb.id: 65318265-4f01-4541-a654-fa74e439dfd3  # ID of an existing load balancer
    kubernetes.io/elb.protocol-port: https:80    # Port where SNI is to be enabled
    kubernetes.io/elb.cert-id: b64ab636f1614e1a960b5249c497a880    # HTTPS server certificate
    kubernetes.io/elb.tls-certificate-ids: 5196aa70b0f143189e4cb54991ba2286,8125d71fcc124aabbe007610cba42d60    # SNI certificate IDs
    kubernetes.io/elb.lb-algorithm: ROUND_ROBIN
spec:
  selector:
    app: test
  externalTrafficPolicy: Cluster
  ports:
    - name: cce-service-0
      targetPort: 80
      nodePort: 0
      port: 80
      protocol: TCP
  type: LoadBalancer
  loadBalancerIP: **.**.**.**       # Private IP address of the load balancer
Table 2 Key parameters

Parameter

Type

Description

kubernetes.io/elb.protocol-port

String

If a Service is HTTP/HTTPS-compliant, configure the protocol and port number in the format of "protocol:port".

where,

  • protocol: specifies the protocol used by the listener port. The value can be http or https.
  • ports: Service ports specified by spec.ports[].port.

For example, to use SNI, the Service protocol must be https and the Service port must be 80. Therefore, the parameter value is https:80.

kubernetes.io/elb.cert-id

String

ID of an ELB certificate, which is used as the HTTPS server certificate.

How to obtain: Log in to the ELB console and choose Certificates. In the certificate list, copy the ID under the target certificate name.

kubernetes.io/elb.tls-certificate-ids

String

In ELB, the IDs of SNI certificates that must contain a domain name are separated by commas (,).

If the server cannot find an SNI certificate matching the client-requested domain name, it will return the default server certificate.

How to obtain: Log in to the ELB console and choose Certificates. In the certificate list, copy the ID under the target certificate name.

kubernetes.io/elb.client-ca-cert-id

String

Required only for mutual authentication. The ELB certificate ID serves as the CA certificate.

How to obtain: Log in to the ELB console and choose Certificates. In the certificate list, copy the ID under the target certificate name.

Dedicated load balancers are available in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later. Shared load balancers are available in clusters v1.28.15-r60, v1.29.15-r20, v1.30.14-r20, v1.31.10-r20, v1.32.6-r20, v1.33.5-r10, or later.

Step 3: Access the Workload

  1. After the Service is created, copy the load balancer's EIP.

  2. Configure DNS for a domain name so that you can use the SNI domain name for browser access. For details, see Adding Record Sets.

  3. View the certificate details returned by the server, such as the issuer, validity period, and SHA-256 fingerprint, in the browser to ensure that the certificate corresponds to the requested SNI domain name.