# Elastic/kibana webserver .p12/.crt issues

**URL:** https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903
**Category:** Elasticsearch
**Created:** [December 5, 2025, 7:05pm UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903 "2025-12-05T19:05:55Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![HaydenB0101](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/haydenb0101/32/146069_2.png) [@HaydenB0101](https://discuss.elastic.co/u/HaydenB0101)
#### Post date: [December 5, 2025, 7:05pm UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903/1 "2025-12-05T19:05:56Z")

</div>

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](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-basic-setup.html) 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:

```auto
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

```auto
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](https://us1.discourse-cdn.com/elastic/original/3X/f/f/ff09e4e6ba7960f160e202acd64e1a84e97bc157.png)

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

---

<div class="post-metadata">

### Author: ![HaydenB0101](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/haydenb0101/32/146069_2.png) [@HaydenB0101](https://discuss.elastic.co/u/HaydenB0101)
#### Post date: [December 9, 2025, 5:14pm UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903/3 "2025-12-09T17:14:56Z")

</div>

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

---

<div class="post-metadata">

### Author: ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [December 9, 2025, 6:27pm UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903/4 "2025-12-09T18:27:18Z")

</div>

> [@HaydenB0101](#):
>
> `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

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...

---

<div class="post-metadata">

### Author: ![HaydenB0101](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/haydenb0101/32/146069_2.png) [@HaydenB0101](https://discuss.elastic.co/u/HaydenB0101)
#### Post date: [December 9, 2025, 7:04pm UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903/5 "2025-12-09T19:04:00Z")

</div>

```auto
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

```

---

<div class="post-metadata">

### Author: ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [December 9, 2025, 8:56pm UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903/6 "2025-12-09T20:56:13Z")

</div>

SO you have proxies

and errors here

```auto
 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

```auto
* 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...

---

<div class="post-metadata">

### Author: ![HaydenB0101](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/haydenb0101/32/146069_2.png) [@HaydenB0101](https://discuss.elastic.co/u/HaydenB0101)
#### Post date: [December 11, 2025, 5:56pm UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903/7 "2025-12-11T17:56:39Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [December 12, 2025, 1:37am UTC](https://discuss.elastic.co/t/elastic-kibana-webserver-p12-crt-issues/383903/8 "2025-12-12T01:37:56Z")

</div>

Hi @HaydenB0101

Sorry I do not understand the response.

> [@HaydenB0101](#):
>
> and the incommon RSA cert i believe comes from the manager I'm trying to connect to

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
