How to configure TLS for Kibana

Configuring TLS for Kibana encrypts browser sessions, login requests, and API traffic before they leave the client. That keeps credentials, session cookies, and dashboard responses off plain HTTP and gives users a certificate-backed way to confirm that they reached the real Kibana endpoint.

Kibana handles two different HTTPS jobs: it can trust Elasticsearch for outbound requests, and it can present its own server certificate for inbound browser traffic. The browser-facing side uses server.ssl.enabled with a certificate and private key that match the host name users actually open in the browser. Elastic's configuration reference supports either a PEM certificate-plus-key pair or a PKCS#12 keystore, but the PEM path is the clearest fit for a focused single-method change.

On DEB and RPM installs, these settings usually live in /etc/kibana/kibana.yml and the TLS assets are commonly kept under /etc/kibana. TLS on the Kibana listener does not replace the separate Elasticsearch connection settings that keep Kibana authenticated to the cluster, so finish that path separately if it is not already working. If the private key is encrypted, store server.ssl.keyPassphrase in the Kibana keystore instead of leaving it in plain text.

Steps to configure TLS for Kibana:

Create a directory for the TLS assets with permissions that let the kibana service read the files without exposing them broadly.
```
$ sudo install -o root -g kibana -m 750 -d /etc/kibana/certs
```
Install the server certificate, private key, and CA certificate or chain that clients should trust for the Kibana endpoint.
```
$ sudo install -o root -g kibana -m 644 /tmp/kibana.crt /etc/kibana/certs/kibana.crt
$ sudo install -o root -g kibana -m 640 /tmp/kibana.key /etc/kibana/certs/kibana.key
$ sudo install -o root -g kibana -m 644 /tmp/kibana-ca.crt /etc/kibana/certs/kibana-ca.crt
```
The server certificate must include the DNS name or IP address that users actually open in the browser as a Subject Alternative Name, or modern browsers will reject the connection even when the CA is trusted.

Tool: SSL Certificate Decoder

Inspect the server certificate subject and Subject Alternative Name entries.

$ openssl x509 -in /etc/kibana/certs/kibana.crt -noout -subject -ext subjectAltName
subject=CN=kibana.example.net
X509v3 Subject Alternative Name:
    DNS:kibana.example.net, DNS:kibana.internal.example.net

Use the exact host name, DNS alias, or IP address that users enter in the browser when checking certificate coverage.

Verify the ownership and file modes before editing the service configuration.

$ sudo ls -l /etc/kibana/certs
total 12
-rw-r--r-- 1 root kibana 1115 Apr  2 14:09 kibana-ca.crt
-rw-r--r-- 1 root kibana 1176 Apr  2 14:09 kibana.crt
-rw-r----- 1 root kibana 1704 Apr  2 14:09 kibana.key

Keep the private key readable only by the service account or a group that the kibana process already belongs to.

Open the Kibana configuration file in a root-owned editor.
```
$ sudoedit /etc/kibana/kibana.yml
```
Archive installs commonly use /usr/share/kibana/config/kibana.yml instead of /etc/kibana/kibana.yml.
Enable inbound HTTPS and point Kibana at the certificate and private key.
```
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/certs/kibana.crt
server.ssl.key: /etc/kibana/certs/kibana.key
```
If the certificate arrives as a PKCS#12 bundle, use server.ssl.keystore.path and its matching password setting instead of server.ssl.certificate plus server.ssl.key. Elastic treats those options as mutually exclusive.

This change secures incoming browser traffic only. Configure elasticsearch.hosts, elasticsearch.username, and any required trust settings separately when Kibana also needs updated backend connectivity.
Related: How to connect Kibana to Elasticsearch
Store server.ssl.keyPassphrase in the Kibana keystore if the private key is encrypted.
```
$ printf '%s' '"replace-with-private-key-passphrase"' | sudo -u kibana env KBN_PATH_CONF=/etc/kibana /usr/share/kibana/bin/kibana-keystore add server.ssl.keyPassphrase --stdin --force
```
Skip this step when the private key is not encrypted. Create the Kibana keystore first if this host does not already have one.
Related: How to create a Kibana keystore

Elastic allows any valid Kibana setting in the keystore, but invalid or extraneous keys can still prevent Kibana from starting.

Related: How to add a secret to a Kibana keystore
Restart the Kibana service so it reloads the TLS settings.
```
$ sudo systemctl restart kibana
```
Related: How to manage the Kibana service with systemctl in Linux
Check that the service returned to an active state after the restart.
```
$ sudo systemctl is-active kibana
active
```
If the service does not return to active, inspect the recent journal for certificate-path, key-permission, YAML, or passphrase errors:
```
$ sudo journalctl -u kibana -n 50 --no-pager
```
Related: How to manage the Kibana service with systemctl in Linux

Request the HTTPS login endpoint with the CA certificate to confirm that Kibana is presenting the expected TLS certificate and answering on port 5601.

$ curl --silent --show-error --include --cacert /etc/kibana/certs/kibana-ca.crt https://kibana.example.net:5601/login
HTTP/2 200
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), display-capture=(), fullscreen=(self), geolocation=(), microphone=(), web-share=()
cross-origin-opener-policy: same-origin
content-security-policy: script-src 'report-sample' 'self'; worker-src 'report-sample' 'self' blob:;
##### snipped #####

A normal 200 OK login response or the expected Kibana security headers confirm that inbound HTTPS is active. If users reach Kibana through a different host name, reverse proxy, or base path, request that published URL instead of the local listener.