I want to ask some point.
sslVerifyServerCert
in outputs.conf
is false
, and requireClientCert
in inputs.conf
is true
by default. In this case, there is no proof on the server side, but it seems that only the client side is proofing.
Is such a setting recommended?https://docs.splunk.com/Documentation/Splunk/7.3.0/Admin/Inputsconf
https://docs.splunk.com/Documentation/Splunk/7.3.0/Admin/Outputsconf
requireClientCert
is false
in indexer side, also configured requireClientCert
is false
in forwarder side.
In this case, I think that it doesn't have to configure clientCert
AND serverCert
, am I wrong?.Hi @yutaka1005,
1- It depends on the security level you wish to have and the trust you put on each layer of your Splunk deployment. If you set the requireClientCert
as you mentioned in your question then your forwarders must present a valid certificate to authenticate and send data to the indexers whereas indexers don't have to present anything to the forwarders since sslVerifyServerCert
is unset in outputs.conf
. With such a configuration you are saying "I trust my indexers to always be the right destination for data so I will not verify the destination where my data is going" and you're also saying "I don't trust my sources so I need to verify that they are legit sources". This guarantees that your sources are always legit and no one can inject noise to your indexers but doesn't guarantee that your forwarder will only send to your indexers. You will need to set both setting if you wish to have both indexers and forwarders verify that they recognize each others. Again it all depends on your security policy.
2- You're right, IfrequireClientCert
is set to false
you can keep the default certs so no need to configure clientCert
or serverCert
.
PS: requireClientCert
defaults to true when default certificates are used.
Let me know if you need further details.
Cheers,
David
Hi @yutaka1005,
1- It depends on the security level you wish to have and the trust you put on each layer of your Splunk deployment. If you set the requireClientCert
as you mentioned in your question then your forwarders must present a valid certificate to authenticate and send data to the indexers whereas indexers don't have to present anything to the forwarders since sslVerifyServerCert
is unset in outputs.conf
. With such a configuration you are saying "I trust my indexers to always be the right destination for data so I will not verify the destination where my data is going" and you're also saying "I don't trust my sources so I need to verify that they are legit sources". This guarantees that your sources are always legit and no one can inject noise to your indexers but doesn't guarantee that your forwarder will only send to your indexers. You will need to set both setting if you wish to have both indexers and forwarders verify that they recognize each others. Again it all depends on your security policy.
2- You're right, IfrequireClientCert
is set to false
you can keep the default certs so no need to configure clientCert
or serverCert
.
PS: requireClientCert
defaults to true when default certificates are used.
Let me know if you need further details.
Cheers,
David
Thank you for answer.
1- Normally, such a environment like web server and client, I think that server side has server cert, and optionally, client have to send client cert to server.
I just wondered that why default value of these attributes is so.
I understand that it is not a recommendation, but it depends on the security level I want! Thank you!
2- OK, I got it!
-PS: requireClientCert defaults to false.
In inputs.conf
, there is below description, so I think default is true, if I use default certification.
requireClientCert = <boolean>
* Determines whether a client must present an SSL certificate to authenticate.
* Full path to the root CA (Certificate Authority) certificate store.
* Default: false (if using self-signed and third-party certificates)
* Default: true (if using the default certificates, overrides the
existing "false" setting)
Most welcome @yutaka1005 !
And yes you're right defaults to true
if using default certificates, I'll update the answer 🙂
Hello, isn't Splunk default certificate considered as selfsigned? Thanks.