Bug 1397568 - External ElasticSearch Non-mutual TLS with Basic Auth results in Unable to verify certificate
Summary: External ElasticSearch Non-mutual TLS with Basic Auth results in Unable to ve...
Keywords:
Status: CLOSED EOL
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Logging
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: ---
Assignee: Peter Portante
QA Contact: Anping Li
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-22 20:28 UTC by Steven Walter
Modified: 2021-06-10 11:41 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-04 20:19:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Steven Walter 2016-11-22 20:28:51 UTC
Description of problem:
This is related but slightly different than the bz at https://bugzilla.redhat.com/show_bug.cgi?id=1395448

When using external elasticsearch with *non-mutual* TLS, AND with basic auth enabled, results in error.


Version-Release number of selected component (if applicable):
3.2.0

How reproducible:
Unverified

Steps to Reproduce:
Created new secret for ca-cert of external ES, updated DC to mount new secret to /etc/fluent/keys
Updated DC environment variables as described in 3.2 install guide:
K8S_HOST_URL                https://kubernetes.default.svc.cluster.local
ES_HOST              example1.example1.test.net
ES_PORT              9200
ES_CLIENT_CERT              
ES_CLIENT_KEY 
ES_CA                   /etc/fluent/keys/ca
OPS_HOST          example1.example1.test.net
OPS_PORT          9200
OPS_CLIENT_CERT          
OPS_CLIENT_KEY             
OPS_CA               /etc/fluent/keys/ca

Got the results in the aforementioned bug, so removed the cert/key but left CA and basic auth info.

Config:
    <match **>
      @type elasticsearch_dynamic
      host example1.example1.test.net
      port 9200
      scheme https
      index_name .operations.${Time.parse(record['time']).getutc.strftime(@logstash_dateformat)}
      user fluentd
      password xxxxxx
      ca_file /etc/fluent/keys/ca
      flush_interval 5s
      max_retry_wait 300
      disable_retry_limit
    </match>
 


Actual results:

Error:
 
2016-11-21 09:46:46 -0500 [warn]: fluent/output.rb:362:rescue in try_flush: temporarily failed to flush the buffer. next_retry=2016-11-21 09:46:47 -0500 error_class="Faraday::SSLError" error="Unable to verify certificate, please set `Excon.defaults[:ssl_ca_path] = path_to_certs`, `ENV['SSL_CERT_DIR'] = path_to_certs`, `Excon.defaults[:ssl_ca_file] = path_to_file`, `ENV['SSL_CERT_FILE'] = path_to_file`, `Excon.defaults[:ssl_verify_callback] = callback` (see OpenSSL::SSL::SSLContext#verify_callback), or `Excon.defaults[:ssl_verify_peer] = false` (less secure)." plugin_id="object:1cb289c"

Expected results:

external elasticsearch and fluentd to connect

Comment 3 Rich Megginson 2016-11-22 21:14:02 UTC
I believe this is a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1395448 or at least very similar.

Comment 5 Steven Walter 2016-11-22 21:29:57 UTC
@Rich

Yes, it is very similar but we hit a different issue when using a different configuration. I didnt want to clutter the other bug with unrelated information if it's not actually the same deal, but if we think it has the same root cause we can move this to the other bz.

Comment 10 Jeff Cantrill 2017-04-04 15:40:40 UTC
Lowering the priority given seems like usecase is small.


Note You need to log in before you can comment on or make changes to this bug.