Unable to verify the first certificate on postman

Hi I've setup a Elastic and Kibana instance on Windows server

Both instances are secured with LetsEncrypt certificate. When I try to use the elasticsearch API on POSTMAN i get the "Unable to verify the first certificate" I am not sure what am I missing. Please advise I dont want to get that error. Its not necessarily post man because the certificate is not verified I am unable to use the elasticsearch API on other applications

However I do get the padlock on browser
elasticsearch.yml is below

http.port: 9600
xpack.security.enabled: true

xpack.security.enrollment.enabled: true

xpack.security.http.ssl:
  enabled: true
  key: C:\Elasticsearch\elasticsearch\config\certs\mydomain.com-key.pem
  certificate: C:\Elasticsearch\elasticsearch\config\certs\mydomain.com-crt.pem

xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12

cluster.initial_master_nodes: ["mynode"]

http.host: 0.0.0.0

kibana.yml

server.port: 5801
server.host: "0.0.0.0"
server.publicBaseUrl: "https://mydomain.com"
server.ssl.enabled: true
server.ssl.certificate: C:\Elasticsearch\kibana\config\cert\mydomain.com-crt.pem
server.ssl.key: C:\Elasticsearch\kibana\config\cert\mydomain.com-key.pem

elasticsearch.hosts: ["https://mydomain.com:9600"]
elasticsearch.username: "kibana_system"
elasticsearch.password: "password"

elasticsearch.ssl.verificationMode: none

Hi @stramzik

Sounds like a Postman issue, perhaps you should check that forum.

If, from your command line you can run this and be successful then elasticsearch is setup correctly

curl -v --cacert /path/to/http_ca.crt -u elastic https://localhost:9200

This seems to be the result of two things:

  1. Postman doesn't trust the issuing certificate from Let's Encrypt
  2. Your ES node is configured to only send the leaf certificate in the SSL handshake

The background info is here

Let's encrypt has an offline root cert, and a separate issuing certificate. That's very normal for a CA.

But what it means is that, if you:

  1. Are using a tool (like Postman, or any other client) that trusts Let's Encrypt's root cert (technically, ISRG's root cert), but knows nothing of the issuing cert, and
  2. Your server has a cert issued by the Let's Encrypt issuer, but does not include a copy of that issuing cert

then, when you point that tool at the server, there's no way for the 2 of them to connect-the-dots. The chain is broken because neither the client or the server has a copy of the intermediate issuing certificate.
The tool trusts anything signed by ISRG, and the server has something that is signed by ISRG, but the only way to know that is if you have a copy of the Let's Encrypt issuing cert (R3).

I don't know if there's a way to change #1 (make Postman know about the LE issuing cert), but you can fix #2 by grabbing the issuing cert (R3) from Let's Encrypt and adding it to the cert chain in your ES instance.

I assume your cert is signed by the R3 issuing cert from Let's Encrypt (there are other possibilities, but they're very unlikely). You can grab that cert from here

To tell ES to use it, you just append it to the existing .crt file you're using.

Here's what you could do on a Linux server.
It looks like you're using Windows, so you'll need to make some adjustments for your needs.

# Get the R3 cert from let's encrypt
curl -o ./lets-encrypt-r3.pem https://letsencrypt.org/certs/lets-encrypt-r3.pem

# Check that it downloaded correctly and looks like a PEM file with a
# -----BEGIN CERTIFICATE-----
# header, etc.
cat ./lets-encrypt-r3.pem

# Add it to the end of your cert chain
cat ./lets-encrypt-r3.pem >> config/certs/mydomain.com-crt.pem
2 Likes

Tim this worked like a charm. Thank you very much you have no idea how helpful your explanation was. I am really gratefully for your response thank you again :pray: :raised_hands: :saluting_face:

2 Likes

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.