Bug 1397568

Summary: External ElasticSearch Non-mutual TLS with Basic Auth results in Unable to verify certificate
Product: OpenShift Container Platform Reporter: Steven Walter <stwalter>
Component: LoggingAssignee: Peter Portante <pportant>
Status: CLOSED EOL QA Contact: Anping Li <anli>
Severity: low Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: aos-bugs, jcantril, misalunk, mmckinst, pportant, rmeggins, stwalter
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-04 20:19:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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.