We're using "verification" and "validation" in the same meaning here - so Fiona's
answer was actually in line with what you are asking. Let me try and clarify
some of the difficulties here so that we're on the same page, and hopefully
it will explain why we don't have a good answer to your question.
As you know, Splunk allows administrators to set any certificates they so desire.
The notion of a "valid SSL cert" is in the eyes of the beholder. For example,
there is nothing "invalid" or "unverifiable" with the default certificates
that ship with Splunk - they are simply self-signed, meaning they won't be recognized
by any system that does not have the Splunk CA certificate installed in its own
root trust chain.
Additionally, it's very common for our customers to use their own internal
CAs and thus internal self-signed certificates, which would also fail "validation"/"verification",
as they are not in the trust chain.
When you say you want to verify the certificate, it can be done in one of two
ways:
Use the normally trusted certificates (e.g. what httplib2 does by default) to
verify against, which will fail if you have a self-signed certificate and did not add it to that
list, even though from a customer's perspective there is nothing wrong with
that cert.
Pass the certificate to validate against, which would mean you need to know
what that certificate is (but then you can ensure you're talking to the right
server).
I think (1) is fraught with peril, as you'll continuously run into cases where
a certificate is "just fine", but you'll mark it as invalid. I think (2) is the
correct thing to do, but it means you need to be able to know which certificates
to verify against, which means you need to read that from the Splunk configuration.
This is also fraught with peril, for a couple of reasons: you need to access
this configuration from disk, as I do not believe it's exposed via REST (though
I am not sure, it may be in /server/settings). You'll then need to be able to access
those certificates (or at least the CA), which again may not be possible (and
even if it is possible today may not always be possible)
In short, I think the best way for you to do this would be:
Have a parameter in your app (e.g. in your conf files) that enables/disables
certificate validation.
Have a parameter (or set of parameters) that the administrator can specify
what certificates to validate against, and then you can do that validation properly.
Hopefully this makes sense.
P.S. I used "validate" and "verify" interchangeably here.
... View more
