> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gcore.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure mutual TLS authentication

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.

<Info>
  mTLS between clients and the Load Balancer is not supported. For client-facing connections, use standard TLS with the `TERMINATED_HTTPS` protocol.
</Info>

## 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.

| Parameter       | Applies to | Purpose                                                   | Endpoint      | Format        |
| --------------- | ---------- | --------------------------------------------------------- | ------------- | ------------- |
| `secret_id`     | Listener   | Server certificate presented to clients                   | `/v2/secrets` | PKCS12        |
| `sni_secret_id` | Listener   | Additional SNI certificates for multi-domain support      | `/v2/secrets` | PKCS12        |
| `secret_id`     | Pool       | Client certificate the Load Balancer presents to backends | `/v2/secrets` | PKCS12 or PEM |
| `ca_secret_id`  | Pool       | CA certificate for verifying backend server certificates  | `/v1/secrets` | PEM           |
| `crl_secret_id` | Pool       | Certificate revocation list                               | `/v1/secrets` | PEM           |

## 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}
```

```json theme={null}
{
  "name": "lb-server-cert",
  "secret_type": "certificate",
  "payload": "<base64-encoded-pkcs12-certificate>",
  "payload_content_type": "application/octet-stream",
  "payload_content_encoding": "base64"
}
```

<Warning>
  Using `payload_content_type: "text/plain"` with base64 encoding causes secret creation to fail. Use `application/octet-stream` instead.
</Warning>

### 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}
```

```json theme={null}
{
  "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}
```

```json theme={null}
{
  "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}
```

```json theme={null}
{
  "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}
```

```json theme={null}
{
  "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}
```

```json theme={null}
{
  "ca_secret_id": "<ca-certificate-secret-id>",
  "secret_id": "<lb-client-certificate-secret-id>"
}
```

<Info>
  Each API call returns a `task_id`. Wait for task completion before proceeding to the next step.
</Info>