---
title: Elasticsearch client certificate authentication on ECK
description: For how ECK secures HTTP traffic and manages TLS certificates, see Manage TLS certificates on ECK. You can configure Elasticsearch to require client certificates...
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7590/deploy-manage/security/k8s-es-client-certificate-auth
products:
  - Elastic Cloud on Kubernetes
applies_to:
  - Elastic Cloud on Kubernetes: Generally available since 3.4
---

# Elasticsearch client certificate authentication on ECK
For how ECK secures HTTP traffic and manages TLS certificates, see [Manage TLS certificates on ECK](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7590/deploy-manage/security/eck-tls).
You can configure Elasticsearch to require client certificates for HTTP authentication, enabling mutual TLS (mTLS) between clients and Elasticsearch. When enabled, clients must present a valid certificate signed by a trusted CA to communicate with Elasticsearch.
<note>
  This requires a valid Enterprise license or Enterprise trial license. Check [the license documentation](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7590/deploy-manage/license/manage-your-license-in-eck) for more details about managing licenses.
</note>


## Enable client certificate authentication

To enable client certificate authentication on Elasticsearch, set `spec.http.tls.client.authentication` to `true`:
```yaml
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 9.4.4
  nodeSets:
  - name: default
    count: 3
  http:
    tls:
      client:
        authentication: true
```

When client authentication is enabled, ECK sets `xpack.security.http.ssl.client_authentication: required` in the Elasticsearch configuration.
The supported Elastic Stack components differ by version. ECK performs the following additional steps depending on your version:
- <applies-to>Elastic Cloud on Kubernetes: Planned</applies-to> Automatically generates and manages client certificates for all Elastic Stack components that connect to Elasticsearch, including stack monitoring sidecars and the AutoOps agent, configuring each to present its certificate when connecting to Elasticsearch.
  <note>
  Fleet Server requires version 8.13.0 or later. If the version is below 8.13.0, ECK blocks pod reconciliation and sets the agent status to red with a warning event.
  </note>
- <applies-to>Elastic Cloud on Kubernetes: Generally available in 3.4</applies-to> The only supported component is Kibana. ECK automatically generates and manages a client certificate for it, configuring it to present its certificate when connecting to Elasticsearch. Other workloads that connect to Elasticsearch over HTTP are not configured automatically.
  <note>
  If you have manually set `xpack.security.http.ssl.client_authentication` in `spec.nodeSets[*].config`, that value takes precedence over the ECK-managed setting and the mTLS configuration may not apply as expected.
  </note>

For Fleet Server acting as the mTLS endpoint (requiring client certificates from connecting Elastic Agents), see [Fleet Server client certificate authentication](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7590/deploy-manage/security/k8s-fleet-server-client-certificate-auth).

## Use a custom client certificate

ECK automatically issues a client certificate to each component. To use your own certificate instead, set `clientCertificateSecretName` in the component's `elasticsearchRef`. When you provide a custom certificate, ECK automatically configures Elasticsearch to trust it — no additional trust configuration is required.
The referenced secret must contain `tls.crt` and `tls.key` entries:
```yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-custom-client-cert
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded certificate>
  tls.key: <base64-encoded private key>
```

<note>
  - `clientCertificateSecretName` can only be used with a named `elasticsearchRef` (not with `secretName`).
  - The secret must be in the same namespace as the resource that references it.
  - All components are compatible with PKCS#8 private keys. If you supply a certificate in a different format, verify compatibility with both Elasticsearch and the individual component before use.
</note>


### Kibana

Set `clientCertificateSecretName` in the `elasticsearchRef` of the Kibana resource:
```yaml
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 9.4.4
  count: 1
  elasticsearchRef:
    name: quickstart
    clientCertificateSecretName: my-custom-client-cert
```


### APM Server

<applies-to>
  - Elastic Cloud on Kubernetes: Planned
</applies-to>

Set `clientCertificateSecretName` in the `elasticsearchRef` of the APM Server resource:
```yaml
apiVersion: apm.k8s.elastic.co/v1
kind: ApmServer
metadata:
  name: quickstart
spec:
  version: 9.4.4
  count: 1
  elasticsearchRef:
    name: quickstart
    clientCertificateSecretName: my-custom-client-cert
```


### Beats

<applies-to>
  - Elastic Cloud on Kubernetes: Planned
</applies-to>

Set `clientCertificateSecretName` in the `elasticsearchRef` of the Beats resource:
```yaml
apiVersion: beat.k8s.elastic.co/v1beta1
kind: Beat
metadata:
  name: quickstart
spec:
  type: filebeat
  version: 9.4.4
  elasticsearchRef:
    name: quickstart
    clientCertificateSecretName: my-custom-client-cert
```


### Enterprise Search

<applies-to>
  - Elastic Cloud on Kubernetes: Planned
</applies-to>

Set `clientCertificateSecretName` in the `elasticsearchRef` of the Enterprise Search resource:
```yaml
apiVersion: enterprisesearch.k8s.elastic.co/v1
kind: EnterpriseSearch
metadata:
  name: quickstart
spec:
  version: 9.4.4
  count: 1
  elasticsearchRef:
    name: quickstart
    clientCertificateSecretName: my-custom-client-cert
```

<warning>
  A bug in Enterprise Search's JRuby runtime can cause startup failures with some PKCS#8 private keys. If Enterprise Search fails to start after enabling client authentication:
  - For operator-managed certificates, delete the affected client certificate secret to force ECK to regenerate it.
  - For custom certificates, regenerate and re-supply the certificate.
</warning>


### Elastic Maps Server

<applies-to>
  - Elastic Cloud on Kubernetes: Planned
</applies-to>

Set `clientCertificateSecretName` in the `elasticsearchRef` of the Elastic Maps Server resource:
```yaml
apiVersion: maps.k8s.elastic.co/v1alpha1
kind: ElasticMapsServer
metadata:
  name: quickstart
spec:
  version: 9.4.4
  count: 1
  elasticsearchRef:
    name: quickstart
    clientCertificateSecretName: my-custom-client-cert
```


### Logstash

<applies-to>
  - Elastic Cloud on Kubernetes: Planned
</applies-to>

Logstash supports multiple Elasticsearch references, so `clientCertificateSecretName` is configured for each entry in `elasticsearchRefs`:
```yaml
apiVersion: logstash.k8s.elastic.co/v1alpha1
kind: Logstash
metadata:
  name: quickstart
spec:
  version: 9.4.4
  count: 1
  elasticsearchRefs:
    - clusterName: production
      name: quickstart
      clientCertificateSecretName: my-custom-client-cert
```

<warning>
  Logstash versions 8.10–8.18 and 9.0 can crash on startup with some PKCS#8 private keys due to a JRuby runtime bug. This is fixed in Logstash 8.19 and 9.1+. If you are running an affected version and Logstash fails to start after enabling client authentication:
  - For operator-managed certificates, delete the affected client certificate secret to force ECK to regenerate it.
  - For custom certificates, regenerate and re-supply the certificate.
</warning>


### Elastic Agent

<applies-to>
  - Elastic Cloud on Kubernetes: Planned
</applies-to>

For standalone Elastic Agent, `clientCertificateSecretName` is configured for each entry in `elasticsearchRefs`:
```yaml
apiVersion: agent.k8s.elastic.co/v1alpha1
kind: Agent
metadata:
  name: quickstart
spec:
  version: 9.4.4
  elasticsearchRefs:
    - name: quickstart
      outputName: default
      clientCertificateSecretName: my-custom-client-cert
```

For Fleet-managed Elastic Agents, Fleet Server automatically propagates the client certificate information to all connected agents. No additional configuration is required.

### Fleet Server

<applies-to>
  - Elastic Cloud on Kubernetes: Planned
</applies-to>

Fleet Server also connects to Elasticsearch and can be configured with a custom client certificate through `elasticsearchRefs`:
```yaml
apiVersion: agent.k8s.elastic.co/v1alpha1
kind: Agent
metadata:
  name: fleet-server
spec:
  version: 9.4.4
  mode: fleet
  fleetServerEnabled: true
  elasticsearchRefs:
    - name: quickstart
      outputName: default
      clientCertificateSecretName: my-custom-client-cert
```

<note>
  Fleet Server requires version 8.13.0 or later to support Elasticsearch client certificate authentication. If the Fleet Server version is below 8.13.0, ECK blocks pod reconciliation and sets the agent status to red with a warning event.
</note>


## Disable client certificate authentication

To turn off client certificate authentication, set `spec.http.tls.client.authentication` to `false` or remove it from the Elasticsearch resource:
```yaml
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  http:
    tls:
      client:
        authentication: false
```

ECK handles the transition gracefully, deferring cleanup of mTLS resources until all pods have rolled over to ensure connectivity is maintained throughout the configuration change.