🚨 Logstash Error Guide: 'PKIX path building failed' — Fix the Elasticsearch Output TLS Trust

Overview

When the Logstash elasticsearch output connects over HTTPS but cannot verify the server’s certificate against a trusted CA, the TLS handshake fails and Logstash logs a PKIX error:

[WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES
instance, but got an error {:url=>"https://es:9200/",
:exception=>Manticore::ClientProtocolException,
:message=>"javax.net.ssl.SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target"}

PKIX path building failed means the JVM’s truststore does not contain the CA that signed Elasticsearch’s certificate, so it cannot build a chain of trust. The connection is refused before any data is sent — this is a certificate-trust problem, not a network or auth problem.

Symptoms

• SSLHandshakeException: PKIX path building failed ... unable to find valid certification path in the log.
• The output stays dead; ingest stalls exactly as with an unreachable ES, but the exception names TLS/PKIX.
• Occurs after switching the ES output from http:// to https://, or after ES certificates were rotated/re-issued.
• openssl s_client to the ES port shows a self-signed or private-CA certificate not in the default trust store.
• Sometimes accompanied by No subject alternative names or certificate_unknown variants (hostname/SAN issues).

Common Root Causes

• Private/self-signed CA not trusted — ES uses an internal CA whose root is not in Logstash’s truststore or cacert.
• Missing cacert/ssl_certificate_authorities — the output points at https:// but no CA file is configured.
• Wrong or incomplete CA chain — only the leaf or an intermediate is provided, not the full path to the root.
• Truststore not updated after cert rotation — ES got a new CA and Logstash still trusts the old one.
• Hostname/SAN mismatch — the certificate does not include the hostname in hosts (surfaces as a related handshake failure).
• Expired certificate — the ES cert or CA expired.

Diagnostic Workflow

Inspect the certificate Elasticsearch actually presents and its issuer chain:

openssl s_client -connect es:9200 -servername es </dev/null 2>/dev/null | \
  openssl x509 -noout -issuer -subject -dates -ext subjectAltName

Verify the chain against your CA file — OK means trust is complete:

openssl s_client -connect es:9200 -CAfile /etc/logstash/certs/ca.crt </dev/null 2>&1 | \
  grep -E 'Verify return code|verify error'

Configure the output to trust the ES CA. In the .conf:

output {
  elasticsearch {
    hosts => ["https://es:9200"]
    user  => "logstash_writer"
    password => "${ES_PW}"
    ssl_enabled => true
    cacert => "/etc/logstash/certs/ca.crt"     # full CA chain to the root
    # ssl_certificate_authorities => ["/etc/logstash/certs/ca.crt"]  # newer syntax
  }
}

Confirm the CA file is complete and readable by the service user:

openssl x509 -in /etc/logstash/certs/ca.crt -noout -subject -issuer -dates
namei -l /etc/logstash/certs/ca.crt

Alternatively, import the CA into the JVM truststore Logstash uses (referenced in jvm.options/LS_JAVA_OPTS):

keytool -importcert -alias es-ca -file /etc/logstash/certs/ca.crt \
  -keystore /etc/logstash/certs/truststore.jks -storepass changeit -noprompt
keytool -list -keystore /etc/logstash/certs/truststore.jks -storepass changeit | grep es-ca

Reload and watch for a restored, verified connection:

kill -SIGHUP $(pgrep -f org.logstash.Logstash)
tail -f /var/log/logstash/logstash-plain.log | grep -Ei 'PKIX|SSLHandshake|Restored'

Example Root Cause Analysis

A team enabled TLS on their Elasticsearch cluster using certificates from their corporate internal CA and updated the Logstash output to https://es:9200. Ingest immediately stopped with PKIX path building failed: unable to find valid certification path.

openssl s_client -connect es:9200 showed the certificate was issued by Corp Internal CA G2 — a private root not present in the JVM’s default trust store. The output had no cacert configured, so Logstash had no way to build a trust path. Running openssl s_client ... -CAfile corp-ca.crt returned Verify return code: 0 (ok), confirming the corporate CA bundle was the correct trust anchor.

They placed the full corporate CA chain at /etc/logstash/certs/ca.crt, added cacert => "/etc/logstash/certs/ca.crt" and ssl_enabled => true to the output, ensured the file was readable by the logstash user, and reloaded. The log then showed Restored connection to ES instance and the queued events flushed. They also added a certificate-expiry monitor so the next rotation would not repeat the outage.

Prevention Best Practices

• Always configure cacert/ssl_certificate_authorities with the full CA chain (up to the root) whenever the ES output uses https://.
• Keep the CA file owned by and readable by the logstash service user; a permission error looks identical to a trust failure.
• When ES certificates are rotated, update Logstash’s CA/truststore in the same change and reload — never rotate one side alone.
• Ensure certificates include the exact hostnames used in hosts as SANs to avoid hostname-verification handshake failures.
• Monitor certificate and CA expiry dates and alert weeks ahead; an expired chain fails the same PKIX way.
• Standardize the truststore path across environments and manage it with configuration management so staging and production trust the same CAs.

Quick Command Reference

# What cert does ES present, and who issued it?
openssl s_client -connect es:9200 </dev/null 2>/dev/null | \
  openssl x509 -noout -issuer -subject -dates -ext subjectAltName

# Does my CA file complete the chain?
openssl s_client -connect es:9200 -CAfile /etc/logstash/certs/ca.crt </dev/null 2>&1 | \
  grep 'Verify return code'

# Import CA into the JVM truststore (alternative to cacert)
keytool -importcert -alias es-ca -file /etc/logstash/certs/ca.crt \
  -keystore /etc/logstash/certs/truststore.jks -storepass changeit -noprompt

# Reload and confirm recovery
kill -SIGHUP $(pgrep -f org.logstash.Logstash)
tail -f /var/log/logstash/logstash-plain.log | grep -Ei 'PKIX|Restored'

Conclusion

PKIX path building failed from the Logstash elasticsearch output is a certificate-trust failure: the JVM cannot build a chain from Elasticsearch’s certificate to a CA it trusts. Diagnose it with openssl s_client to see the issuer, then confirm your CA bundle completes the chain with -CAfile. The fix is to point cacert/ssl_certificate_authorities at the full CA chain (or import it into the JVM truststore), owned readably by the logstash user. Rotate certs on both sides together and monitor expiry so TLS trust never silently stalls ingest.