Elastic/kibana webserver .p12/.crt issues

Elastic Stack Elasticsearch
1

My elastic setup is running into issues after I generated new certs for http encryption using elasticsearch-certutil for http and ca. I followed this documentation as well as documentation from other people Kibana is running for my webserver, but logs return the following:

sudo journalctl -u kibana -f “Unable to retrieve version information from Elasticsearch nodes. self-signed certificate in certificate chain”

curl -vk manageraddress --cacert /etc/elasticsearch/certs/http_ca.crt [ERROR][elasticsearch-service] Unable to retrieve version information from Elasticsearch nodes. self-signed certificate in certificate chain

this is what i currently have in each yml file:
elasticsearch.yml:

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: /etc/elasticsearch/http.p12
xpack.security.transport.ssl.truststore.password: "password"

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/transport.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/ca.p12
xpack.security.transport.ssl.truststore.password: "password"

kibana.yml

elasticsearch.ssl.verificationMode: certificate
elasticsearch.ssl.certificateAuthorities: "/etc/kibana/http_ca.crt"

elasticsearch.ssl.truststore.path: "/etc/elasticsearch/http.p12"
elasticsearch.ssl.truststore.password: "password"
xpack.encryptedSavedObjects.encryptionKey: "key"

my webserver has this error currently:

image
image708×122 10.4 KB

Could there be an issue regarding passwords for the certs between servers?

3

I’m looking at some things and am trying to understand if i would need to generate new elasticsearch certs on the server that this is trying to connect to, or if i would need to copy the .p12 bundle i created with elasticsearch-certutil

4

Since you did not show the entire command and result it is hard for use to debug.

Often these issues are because of how access the resource (hostname, IP etc) vs the SANS etc in the cert do NOT match.. and thus fails... very common

if you show that command with the ENTIRE output, we might be able to help

although curl is on the http layer and transport is not...

5 
curl -vk address --cacert /etc/elasticsearch/certs/http_ca.crt
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,::1'
* Uses proxy env variable https_proxy == 'http://webproxy:8080'
*   Trying proxy:8080...
* Connected to (nil) (proxy) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to address:443
> CONNECT address:443 HTTP/1.1
> Host: address:443
> User-Agent: curl/7.81.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=----; O=----; CN=address
*  start date: Sep  9 00:00:00 2025 GMT
*  expire date: Oct 10 23:59:59 2026 GMT
*  issuer: C=US; O=Internet2; CN=InCommon RSA Server CA 2
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /kibana/ HTTP/1.1
> Host: address
> User-Agent: curl/7.81.0
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Tue, 09 Dec 2025 19:00:49 GMT
< Server: Apache/2.4.52 (Ubuntu)
< Strict-Transport-Security: max-age=15552000; includeSubDomains
< Set-Cookie: _opensaml_req_ss%3Amem%3A16e75428610ffe78ba34cec4f86786e092d2429cea3abf1ff87a281ca682a3f0=_298578a7b8fb05f0021f142279fcc19d; path=/; secure; HttpOnly; SameSite=None
< Expires: Wed, 01 Jan 1997 12:00:00 GMT
< Cache-Control: private,no-store,no-cache,max-age=0
< Location: https://---
< Content-Length: 929
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href=---">here</a>.</p>
<hr>
<address>Apache/2.4.52 (Ubuntu) Server at address Port 443</address>
</body></html>
* Connection #0 to host (nil) left intact
6

SO you have proxies

and errors here

 Server certificate:
*  subject: C=US; ST=----; O=----; CN=address
*  start date: Sep  9 00:00:00 2025 GMT
*  expire date: Oct 10 23:59:59 2026 GMT
*  issuer: C=US; O=Internet2; CN=InCommon RSA Server CA 2
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

So yes you have certificate issues....

What I would do is get the certs working without proxies ...
Looks like you have issues on HTTP and transport interfaces...

You indicated you followed the documents

But this

*  issuer: C=US; O=Internet2; CN=InCommon RSA Server CA 2

does not look like an elastic generated cert but perhaps I am wrong

What version are you on...

7

I currently running 8.19.7
i generated certs on my webserver using elasticsearch-certutil, and the incommon RSA cert i believe comes from the manager I'm trying to connect to, since it has an officially signed cert.

8

Hi @HaydenB0101

Sorry I do not understand the response.

In short Elastic / Kibana handling of certs if "generic" there is nothing really special about how they are handled.

HTTO can be testing with curl if the curl works with the same parameters, the Elastic and Kibana will work. (meaning no -k. proper CA, proper IP / host name etc.)

Transport interface in not HTTP so maybe a little harder to debug but that is also basic cert operational stuff.

One you start using your own certs, proxies etc you will need to figure that all out