Skip to main content
Gcore Load Balancers support mutual TLS (mTLS) — both the Load Balancer and backend servers verify each other’s certificates, preventing connections from unauthorized endpoints in either direction.

​
Supported configurations

TLS can be configured for two different communication paths:
  • Client to Load Balancer (TLS): Standard TLS termination using TERMINATED_HTTPS protocol. The Load Balancer presents a server certificate to clients.
  • Load Balancer to backend servers (mTLS): Mutual TLS where both the Load Balancer and backend servers exchange and verify certificates.
mTLS between clients and the Load Balancer is not supported. For client-facing connections, use standard TLS with the TERMINATED_HTTPS protocol.

​
Certificate parameters

Each path uses different certificate parameters stored via different API endpoints. Listener certificates use /v2/secrets, which supports PKCS12 binary format; pool CA certificates and CRLs use /v1/secrets for PEM text format. The split is intentional — the endpoints store different certificate formats.
ParameterApplies toPurposeEndpointFormat
secret_idListenerServer certificate presented to clients/v2/secretsPKCS12
sni_secret_idListenerAdditional SNI certificates for multi-domain support/v2/secretsPKCS12
secret_idPoolClient certificate the Load Balancer presents to backends/v2/secretsPKCS12 or PEM
ca_secret_idPoolCA certificate for verifying backend server certificates/v1/secretsPEM
crl_secret_idPoolCertificate revocation list/v1/secretsPEM

​
TLS termination

The steps below configure a new load balancer with a TERMINATED_HTTPS listener.

​
Step 1. Create server certificate secret

Create a PKCS12 certificate bundle using the /v2/secrets endpoint: 
POST /v2/secrets/{project_id}/{region_id}

{
  "name": "lb-server-cert",
  "secret_type": "certificate",
  "payload": "<base64-encoded-pkcs12-certificate>",
  "payload_content_type": "application/octet-stream",
  "payload_content_encoding": "base64"
}
Using payload_content_type: "text/plain" with base64 encoding causes secret creation to fail. Use application/octet-stream instead.

​
Step 2. Create listener with TLS termination

Create a load balancer with a TERMINATED_HTTPS listener referencing the server certificate: 
POST /v1/loadbalancers/{project_id}/{region_id}

{
  "name": "https-lb",
  "flavor": "lb1-1-2",
  "vip_network_id": "<network-id>",
  "listeners": [
    {
      "name": "https-listener",
      "protocol": "TERMINATED_HTTPS",
      "protocol_port": 443,
      "secret_id": "<server-certificate-secret-id>",
      "pools": [
        {
          "name": "backend-pool",
          "protocol": "HTTP",
          "lb_algorithm": "ROUND_ROBIN",
          "members": [
            {
              "address": "192.168.1.10",
              "protocol_port": 80
            }
          ]
        }
      ]
    }
  ]
}

​
mTLS for backend connections

The steps below create the certificate secrets and a pool with mTLS parameters for an existing load balancer.

​
Step 1. Create CA certificate secret

Create a PEM CA certificate using the /v1/secrets endpoint: 
POST /v1/secrets/{project_id}/{region_id}

{
  "name": "backend-ca-cert",
  "secret_type": "certificate",
  "payload": "<base64-encoded-pem-ca-certificate>",
  "payload_content_type": "application/octet-stream",
  "payload_content_encoding": "base64"
}

​
Step 2. (Optional) Create Load Balancer client certificate

If backend servers require client authentication, create a certificate that the Load Balancer presents to backends: 
POST /v2/secrets/{project_id}/{region_id}

{
  "name": "lb-client-cert",
  "secret_type": "certificate",
  "payload": "<base64-encoded-pkcs12-or-pem-certificate>",
  "payload_content_type": "application/octet-stream",
  "payload_content_encoding": "base64"
}

​
Step 3. Create pool with mTLS configuration

Create a pool with HTTPS protocol and mTLS parameters: 
POST /v1/lbpools/{project_id}/{region_id}

{
  "name": "secure-backend-pool",
  "protocol": "HTTPS",
  "lb_algorithm": "ROUND_ROBIN",
  "load_balancer_id": "<loadbalancer-id>",
  "ca_secret_id": "<ca-certificate-secret-id>",
  "secret_id": "<lb-client-certificate-secret-id>",
  "members": [
    {
      "address": "192.168.1.20",
      "protocol_port": 443
    }
  ]
}
The ca_secret_id parameter enables the Load Balancer to verify backend server certificates. The secret_id parameter provides the client certificate for mutual authentication.

​
mTLS on an existing load balancer

An existing pool’s mTLS configuration can be updated without recreating the load balancer. Create the required CA certificate via POST /v1/secrets and, if needed, the client certificate via POST /v2/secrets, then send a PATCH request with the certificate secret IDs: 
PATCH /v2/lbpools/{project_id}/{region_id}/{pool_id}

{
  "ca_secret_id": "<ca-certificate-secret-id>",
  "secret_id": "<lb-client-certificate-secret-id>"
}
Each API call returns a task_id. Wait for task completion before proceeding to the next step.