Logstash is unable to push logs to elasticsearch even ssl verify is set to fals

Elastic Stack Logstash
1

Dear Friends,

I have enabled TLS/SSL in my elasticsearch latest version and all my filebeat, metricbeats are working perfectly.

However, logstash is unable to connect to elasticsearch after enabling TLS and return the below error : below error

[WARN ] 2021-06-09 18:07:16.339 [Ruby-0-Thread-5: :1] elasticsearch - Attempted to resurrect connection to dead ES instance, but got an error. {:url=>"https://logstash_shipper:xxxxxx@149.129.128.87:10200/", :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [https://logstash_shipper:xxxxxx@149.129.128.87:10200/][Manticore::ClientProtocolException] PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"}

I have specified ssl_certificate_version ==> false in my logstash's output configuration, but still no luck.

Here is my logstash pipeline configuration :

elasticsearch {
            hosts => ["https://1.2.3.4:10200"]
            index => "index-accesslogs-%{+YYYY.MM.dd}"
            #document_id => "%{message}"
            document_id => "%{[@metadata][fingerprint]}"
            user => XXXXXXXXXXXX
            password => XXXXXXXXXXX
            ssl => true
            ssl_certificate_verification => false
             }

I have the below new files generated as part of enabling TLS exercise but dont have crt certificate to add into java keystore.

elastic-certificates.p12
http.p12
elasticsearch.keystore

Please suggest.

Thanks for your time in advance!!!

2

ssl_certificate_version disables the requirement for a name-matched certificate (i.e. if you connect to https://1.2.3.4:10200 the certificate must have a name, or subject alternate name, of 1.2.3.4). Setting this is a terrible idea, for reasons that the PDF linked to in the documentation explain.

However, even with a certificate that is not name-matched, there is no reason to allow a TLS connection to use an untrusted certificate when any certificate can be trusted based on either the CA (using the cacert option on the output) or by adding the certificate (including the intermediates, and possibly even the root) to the file pointed at by the truststore option.

If you do not know how to extract the CA or to save a certificate and its intermediates from a website I suggest you take a look at one of the StackExchange sites. I do not know, off the top of my head, which one would be appropriate.

3

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