# Invalid or malformed certificate using caFingerprint

**URL:** <https://discuss.elastic.co/t/invalid-or-malformed-certificate-using-cafingerprint/349754>\
**Category:** Elasticsearch\
**Created:** [December 20, 2023, 10:29pm UTC](https://discuss.elastic.co/t/invalid-or-malformed-certificate-using-cafingerprint/349754 "2023-12-20T22:29:32Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\
**Post date:** [December 22, 2023, 5:14am UTC](https://discuss.elastic.co/t/invalid-or-malformed-certificate-using-cafingerprint/349754/11 "2023-12-22T05:14:55Z")

</div>

> [@joe\_recra](#):
>
> I created a CA to generate elastic and kibana certs, I dind use http\_ca.crt to sign them.

Can you explain why you decided to do this?  
The out of the box configuration is designed to make everything work simply and easily without all this messing around. What was your motivation for changing it?

I suspect the problem is here:

> [@joe\_recra](#):
>
> ```auto
> # Enable encryption for HTTP API client connections, such as Kibana, Logstash, and Agents
> xpack.security.http.ssl:
> enabled: true
> certificate: certs/elastic/elastic.crt
> key: certs/elastic/elastic.key
> certificate_authorities: certs/ca/ca/ca.crt
> #keystore.path: certs/http.p12
> 
> ```

`xpack.security.http.ssl.certificate_authorities` doesn't do what you think it does. It is used to validate client certificates. Since you aren't using client certificates, this line achieves nothing.

What you seem to be trying to do is provide the issuing chain for the server certificate. In Elasticsearch you do that by concatating the issuing chain with the server certificate.

See the explanation and example commands here

- [Unable to verify the first certificate on postman - #3 by TimV](https://discuss.elastic.co/t/unable-to-verify-the-first-certificate-on-postman/344071/3)

As it is, it doesn't looks like you have configured Elasticsearch to send the CA certificate over the wire, so the client cannot verify the fingerprint.

Is there a particular reason you want to use the CA fingerprint rather than just [trusting the CA cert itself](https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/client-connecting.html#auth-tls)?  
The fingerprint is a simple option when you use security auto configuration because the CA fingerprint is included in the node's output when it is set up, but if you're using your own cert then there's no real benefit to a fingerprint

---

_[View the full topic](https://discuss.elastic.co/t/invalid-or-malformed-certificate-using-cafingerprint/349754)._