Cannot specify SSL verify_mode or CA chain

[matthewdooler]

I'm having trouble connecting to an SSL-cert-protected Splunk instance because there is no way to set the SSL verify_mode to VERIFY_PEER and pass in a CA chain. I can set my cert and key but since there is no way to pass the full CA chain which contains the required intermediate certs, then authentication fails.

The root of the problem is that the verify mode is currently hard-coded to VERIFY_NONE in lib/splunk-sdk-ruby/context.rb. This seems to be analogous to the --insecure curl flag, which doesn't just ignore the server cert but also breaks authentication when intermediate certs need to be passed in.

A potential fix to the splunk sdk would be to allow verify_mode and the path to the CA chain to be passed in, which would then be set inside context.rb (the verify_mode and ca_file attributes on Net::HTTP and ssl_context.verify_mode). I can provide a full example if that would help.

Is it likely that this could be fixed? I really can't think of a way of working around this without actually changing the sdk.

Version of project: 1.0.5
Platform version: Mac OS X and Linux
Framework version: Ruby 2.2.0
Splunk version: Splunk 6.1.3

[itay]

@matthewdooler thanks for the bug report. A couple of things:

1. Do you think it would be possible to get an example, as you suggested? Basically, the config on the Splunk side (with the relevant certs) and then the config and certs on the SDK side? That way it should be a lot easier to see what the fix should be.
2. As always, we're open to Pull Request contributions to fix the issue :)

[matthewdooler]

I don't have admin access to the Splunk instance so can't pull down the exact config, but basically the setup is like this:

• there's a root CA and two intermediate CAs issued by the root (call them CA1 and CA2).
• the server (Splunk) has a cert issued by CA1 and only trusts clients presenting certificates issued by the CAs in its trust chain (which are CA1 and the root).
• the client has a cert issued by CA2. The server has no knowledge of CA2 but will trust it if the client sends the actual CA2 intermediate cert when making the request (in addition to its own client certificate). This works because the server trusts the root CA, implicitly trusting CA2 or any other child of the root provided it can verify the intermediate cert was actually issued by root. It can only do this if it's actually sent a copy of the intermediate cert.

Does this help clear things up? If not, the fix should actually be quite easy so I can submit a PR if it's likely to be accepted!

[imechemi]

@matthewdooler Can I relate this https://gist.github.com/imechemi/785f839a1f162e52096f6b4216538a41 as well over here?