Sense fails with SSL (using own RootCA)

[elastic]

Sense fails with SSL (using own RootCA)

[inqueue]

@sherzberg Until the Sense plugin is fixed, the workaround is adding rejectUnauthorized: false to installedPlugins/sense/index.js.

--- index.js.old    2015-12-01 19:36:46.000000000 -0500
+++ index.js    2015-12-01 17:41:14.000000000 -0500
@@ -71,6 +71,7 @@
               },
               passThrough: true,
               xforward: true,
+              rejectUnauthorized: false,
          onResponse: function (err, res, request, reply, settings, ttl) {
                 if (err != null) {
                   reply("Error connecting to '" + request.query.uri + "':\n\n" + err.message).type("text/plain").statusCode = 502;

Restart Kibana after patching.

CAUTION: This effectively disables certificate verification in the Sense plugin proxy handler. Use at your own risk!

[spalger]

Note to anyone following along, beta4 only allowed GET requests to be proxied. Just released beta5 which fixes this. Updated #69 (comment) as well.

./bin/kibana plugin --install elasticsearch/sense/2.0.0-beta5

[bleskes]

@spalger does it make sense to add these SSL config options to the Sense proxy?

[spalger]

Yeah, it's tricky to say because those ssl parameters are only useful for a subset of the possible servers the proxy will connect to. Used in tandom with the proxyFilter setting it makes some more sense, but then we need to ssl settings for different domains (which seems gross).

Maybe we should try to find a way to learn if the server's ssl is not verifiable and then just show that to the user (like a browser would, maybe with a red fa-unlock-alt).

Another option we have is to allow users to extend the root CA's that sense (or even kibana) use with the ssl-root-cas module... This feels like the preferred option to me and is something we can implement in sense today and extend to the entire server at a later time.

[bleskes]

Maybe we should try to find a way to learn if the server's ssl is not verifiable and then just show that to the user (like a browser would, maybe with a red fa-unlock-alt).

That's sounds promising, but I think that just the lock is too subtle (unless we have the server drop down list). Have a more prominent error/warning bar would be good, but then we need to migrate all proxy errors there. Shouldn't be too much but I'm not sure we should embark down that road where we haven't pinned down the UI changes.

extend the root CA's that sense

Allowing to add a custom CA sounds like a good solution to me. I'm +1 on that.

Alternatively, if that turns out complicated, we can also just add a "allow unverified ssl" (to be named better) setting that allows to connect anyway (the equivalent to people authorizing it in the browser).

[GlenRSmith]

👍 to finding a solution

[sherzberg]

Until a proper solution is implemented, are there any workarounds?

[spalger]

The only real workaround @sherzberg would be to patch the source. If you are interested in that approach you would need to patch the proxy config of sense's main proxy path and either tell it to use a custom Node.js SSL Agent or stop rejecting unauthorized requests.

[sherzberg]

@spalger thanks for some direction! I am going to try and patch this until a more appropriate fix is available.

[nellicus]

thanks @inqueue for that!

@spalger @bleskes is there a timeline for fixing this? this effectively prevents any use of Sense

[jakommo]

👍

[allenmchan]

+1

[spalger]

I released 2.0.0-beta3 Friday, Feb 26, with support for disabling SSL verification via the kibana.yml configuration.

Install the latest version of sense with bin/kibana plugin --install elastic/sense and add the sense.ssl.verify: false setting to your kibana.yml file to temporarily workaround this issue.

For now I'll be keeping this issue open so that we can work for an actual solution at will allow properly verifying self-signed certificates without modifying the source code.

[spalger]

I'm working on a solution that will allow you to map ssl settings to hostname patterns. Should have a PR online early tomorrow

[spalger]

Alright, just pushed sense 2.0.0-beta4beta5. This version includes a new sense.proxyConfig configuration option that allows specifying proxy configuration based on the target of proxy requests.

The option is detailed in the installation docs and in this pull request.

Until the "latest" redirect is updated, install 2.0.0-beta4beta5 explicitly by telling kibana the version number:

./bin/kibana plugin --install elasticsearch/sense/2.0.0-beta5

[sherzberg]

I just tried this and got this in my logs and kibana exited:

{"type":"log","@timestamp":"2016-03-11T17:34:40+00:00","tags":["fatal"],"pid":71,"level":"fatal","message":"child \"sense\" fails because [child \"proxyConfig\" fails because [\"proxyConfig\" at positi
on 0 fails because [\"match.protocol\" is not allowed, \"ssl.verify\" is not allowed]]]","error":{"message":"child \"sense\" fails because [child \"proxyConfig\" fails because [\"proxyConfig\" at position 0 fails
 because [\"match.protocol\" is not allowed, \"ssl.verify\" is not allowed]]]","name":"ValidationError","stack":"ValidationError: child \"sense\" fails because [child \"proxyConfig\" fails because [\"proxyConfig\
" at position 0 fails because [\"match.protocol\" is not allowed, \"ssl.verify\" is not allowed]]]\n    at Object.exports.process (/opt/kibana/node_modules/joi/lib/errors.js:140:17)\n    at [object Object].intern
als.Any._validateWithOptions (/opt/kibana/node_modules/joi/lib/any.js:649:25)\n    at [object Object].root.validate (/opt/kibana/node_modules/joi/lib/index.js:102:23)\n    at Config._commit (/opt/kibana/src/serve
r/config/Config.js:134:25)\n    at Config.set (/opt/kibana/src/server/config/Config.js:104:12)\n    at Config.extendSchema (/opt/kibana/src/server/config/Config.js:69:14)\n    at ScopedPlugin.readConfig$ (/opt/ki
bana/src/server/plugins/Plugin.js:68:20)\n    at tryCatch (/opt/kibana/node_modules/babel-runtime/regenerator/runtime.js:67:40)\n    at GeneratorFunctionPrototype.invoke [as _invoke] (/opt/kibana/node_modules/bab
el-runtime/regenerator/runtime.js:315:22)\n    at GeneratorFunctionPrototype.prototype.(anonymous function) [as next] (/opt/kibana/node_modules/babel-runtime/regenerator/runtime.js:100:21)\n    at GeneratorFuncti
onPrototype.invoke (/opt/kibana/node_modules/babel-runtime/regenerator/runtime.js:136:37)\n    at run (/opt/kibana/node_modules/babel-core/node_modules/core-js/modules/es6.promise.js:104:47)\n    at /opt/kibana/n
ode_modules/babel-core/node_modules/core-js/modules/es6.promise.js:115:28\n    at flush (/opt/kibana/node_modules/babel-core/node_modules/core-js/modules/$.microtask.js:19:5)\n    at nextTickCallbackWith0Args (no
de.js:415:9)\n    at process._tickDomainCallback (node.js:385:13)"}}
FATAL { [ValidationError: child "sense" fails because [child "proxyConfig" fails because ["proxyConfig" at position 0 fails because ["match.protocol" is not allowed, "ssl.verify" is not allowed]]]]
...

Here is my sense configuration in kibana.yml:

sense.proxyConfig:                                                                                                                                                                                            
  - match.protocol: "https"
    ssl.verify: false

What am I missing?

[sherzberg]

Sorry, I should be more clear, i tried the beta4 in my last post. So beta4 is not working for me.

beta3 seems to work fine with just sense.ssl.verify: false.

[spalger]

@sherzberg sorry, I messed up the doc. Until elastic/kibana#6518 is fixed properties within the proxyConfig list can't use dot-separated key names.

Updated the docs in the repo and they should be updated on elastic.co soon (once CI runs).

[sherzberg]

@spalger Awesome, thanks for the quick response! The non-dotted paths worked fine on beta5.

[yt449]

Tried to install sense, however got the message:

Installing sense
Attempting to transfer from https://download.elastic.co/elasticsearch/sense/sense-2.0.0-beta5.tar.gz
Error: Client request error: self signed certificate in certificate chain
Plugin installation was unsuccessful due to error "Client request error: self signed certificate in certificate chain"