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.
Related: How to connect Kibana to Elasticsearch
Related: How to set the Kibana server host
Related: How to set the Kibana public base URL
Related: How to add a secret to a Kibana keystore
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.netUse 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 keystoreElastic allows any valid Kibana setting in the keystore, but invalid or extraneous keys can still prevent Kibana from starting.
- Restart the Kibana service so it reloads the TLS settings.
$ sudo systemctl restart kibana
- 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
- 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.
Related: How to check Kibana status
Related: How to set the Kibana public base URL
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.