Diagnosing Kibana HTTPS Connection Failures to Elasticsearch

Problem and takeaway

Kibana cannot complete its startup handshake with Elasticsearch when Elasticsearch is configured for HTTPS. The browser may show a certificate error, or Kibana may keep displaying “Kibana server is not ready yet.” The useful takeaway is that nearly all of these failures come from one of three causes: Kibana does not trust the certificate authority that signed Elasticsearch’s certificate, the Elasticsearch certificate lacks a subject alternative name matching the hostname Kibana uses, or the security mode on Kibana does not match Elasticsearch. Verify connectivity from the command line before editing kibana.yml.

Recognizable condition

You are likely facing a TLS or trust issue if any of the following appear after Kibana starts:

• The Kibana UI shows “Kibana server is not ready yet” for several minutes.
• The browser reports a certificate error, such as an untrusted or mismatched certificate, when opening Kibana.
• Kibana logs contain SSL handshake failures, “certificate verify failed,” or unauthorized connection errors after Elasticsearch TLS is enabled.

Cause and diagnostic table

Observed symptom	Most likely cause	First check
“Kibana server is not ready yet” after restart	Missing CA trust file, or the Kibana OS user cannot read it	Run curl --cacert against Elasticsearch port 9200
Browser certificate or hostname mismatch warning	Elasticsearch certificate SAN does not match the hostname in elasticsearch.hosts	Run openssl s_client -showcerts and inspect the SAN
Connection or authentication failures after enabling TLS	xpack.security.enabled mismatch between Elasticsearch and Kibana	Compare security settings in both configuration files

Ordered checks

1. Check 1: Confirm Elasticsearch answers over HTTPS

   Run this from the Kibana server or any host that can reach the Elasticsearch endpoint. No special permissions are required.

   curl --cacert /etc/kibana/certs/ca.crt https://:9200

   Expected result: an HTTP 200 response containing Elasticsearch version JSON. If this fails, the problem is likely network reachability or the CA file, not Kibana configuration. Risk: none; this is a read-only request.

2. Check 2: Inspect the certificate chain and hostname

   Run from the Kibana server. No special permissions are required.

   openssl s_client -connect :9200 -servername  -showcerts

   Expected result: the leaf certificate is issued by the CA listed in Kibana’s configuration, and the certificate’s subject alternative name includes . Risk: none; this only reads certificate data presented during a TLS handshake.

3. Check 3: Review Kibana TLS settings

   Run on the Kibana server as the kibana user or with root privileges.

   grep -E 'elasticsearch.ssl|xpack.security|elasticsearch.hosts' /etc/kibana/kibana.yml

   Expected result: elasticsearch.hosts uses https://, elasticsearch.ssl.certificateAuthorities points to an existing PEM bundle, and elasticsearch.ssl.verificationMode is not set to none in production. Configuration key names can differ between Kibana 7.x and 8.x; verify them against the documentation for your installed version before editing.

4. Check 4: Confirm the Kibana process can read the CA file

   Run on the Kibana server.

   ls -l /etc/kibana/certs/ca.crt
   sudo -u kibana cat /etc/kibana/certs/ca.crt > /dev/null

   Expected result: the file exists and the kibana OS user can read it without a permission error. Risk: none.

5. Check 5: Compare security mode on both sides

   Inspect Elasticsearch and Kibana configuration files.

   grep -n 'xpack.security.enabled' /etc/elasticsearch/elasticsearch.yml /etc/kibana/kibana.yml

   Expected result: both files show the same value, typically true on a secured cluster. Risk: none for reading; changing this value requires a service restart.

Fixes tied to findings

Fix 1: Add or correct the certificate authority bundle

If Check 1 or Check 4 failed, set elasticsearch.ssl.certificateAuthorities in kibana.yml to a PEM bundle containing the Elasticsearch CA. Make the file readable by the kibana user, then restart Kibana.

elasticsearch.ssl.certificateAuthorities: /etc/kibana/certs/ca.crt

Change ownership and permissions as needed, for example:

chown root:kibana /etc/kibana/certs/ca.crt
chmod 640 /etc/kibana/certs/ca.crt
systemctl restart kibana

Rollback: keep a backup copy of kibana.yml before editing. If the change does not resolve the issue, restore the backup and restart Kibana again.

Fix 2: Match the certificate hostname to Kibana’s target

If Check 2 showed a SAN mismatch, align elasticsearch.hosts with a name on the certificate, or reissue the Elasticsearch certificate with a subject alternative name that matches the hostname Kibana uses.

elasticsearch.hosts: ["https://:9200"]

Do not set elasticsearch.ssl.verificationMode to none or certificate to work around a hostname mismatch in production. Disabling verification exposes traffic to interception. The certificate mode is acceptable only for temporary, non-production testing.

Fix 3: Align security mode between Elasticsearch and Kibana

If Check 5 found a mismatch, set xpack.security.enabled to the same value on both Elasticsearch and Kibana, typically true, then restart both services. Coordinating restarts matters because TLS changes on Elasticsearch can also affect Beats, Logstash, Fleet, and other clients targeting the same endpoint.

Limitations and practical verification

This guide covers trust, hostname, and security-mode mismatches. It does not cover load balancer termination, Elasticsearch certificate expiration, or Kibana server certificate configuration for end-user browsers.

After applying a fix, verify with:

• curl --cacert /etc/kibana/certs/ca.crt https://:9200 returning HTTP 200.
• openssl s_client -connect :9200 -servername -showcerts showing a chain to the configured CA.
• Kibana logs, via journalctl -u kibana or kibana.log, showing successful startup instead of SSL handshake or unauthorized errors.

Escalation criteria

Escalate to the platform team or Elastic support if:

• curl with the CA bundle succeeds, but Kibana still cannot connect. Collect SSL handshake stack traces from kibana.log or journalctl -u kibana before opening the ticket.
• The Elasticsearch certificate is self-signed or issued by an internal CA that cannot be changed, and production traffic cannot be re-encrypted through a trusted intermediary.
• Changing TLS settings breaks other clients such as Beats, Logstash, or Fleet after the Kibana restart.