Related Answers
Download topic as PDF
Configure Splunk forwarding to use the default certificate
The default root certificate that ships with Splunk software is the same root certificate in every download. Splunk software uses these certificates by default and you should not need to configure them unless they have been removed or corrupted.
Default certificates are not considered highly secure. Anyone who has downloaded Splunk Enterprise has server certificates signed by the same root certificate and are able to authenticate to your certificates. To ensure that no one can easily snoop on your traffic or wrongfully send data to your indexers, we recommend that you replace them with signed certificates.
Important: The default certificates are set to expire three years after they are generated and new certificates must be created and configured at that time using one of the methods described in this manual.
To configure your forwarders to use certificates signed by your own root CA or a third-party CA see Configure Splunk forwarding to use your own certificates.
In this topic we describe how to:
- Configure the indexer to use the default certificates that ship with Splunk software
- Configure the forwarder to use the default certificates that ship with Splunk software
Set up the indexer to use the default server certificate
1. In $SPLUNK_HOME/etc/system/local/inputs.conf (or the appropriate directory of any app you are using to distribute your forwarding configuration), set up the following stanzas:
[splunktcp-ssl:9997] disabled = 0 [SSL] serverCert = Absolute path to the certificate. The default certificate is $SPLUNK_HOME/etc/auth/server.pem sslPassword = password requireClientCert= false (There is no need validate the default server certificate)
2. Your server.conf should also have the following (skip this for Windows configurations):
[sslConfig] sslRootCAPath = /opt/splunk/etc/auth/cacert.pem
3. Restart splunkd:
Configure the forwarder
Set up your forwarder to use the same default certificates as your indexer and configure the forwarder to send data to the configured listening port.
1. Define the following stanzas in $SPLUNK_HOME/etc/system/local/outputs.conf (or in the appropriate directory of any app you are using to distribute your forwarding configuration):
[tcpout:group1] server = 10.1.12.112:9997 clientCert = $SPLUNK_HOME/etc/auth/server.pem sslPassword = password sslVerifyServerCert = false
2. Your forwarder's server.conf should also have the following:
Linux:
[sslConfig] sslRootCAPath = /opt/splunkforwarder/etc/auth/cacert.pem
Windows:
caCertFile = cacert.pem caPath = $SPLUNK_HOME\etc\auth
3. Restart splunkd:
Next steps
Next, you should check your connection to make sure your configuration works. See "Validate your configuration" for more information.
|
PREVIOUS About securing data from forwarders |
NEXT Configure Splunk forwarding to use your own certificates |
This documentation applies to the following versions of Splunk® Enterprise: 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.3.0, 7.3.1
Comments
Bkessler, this is a great idea, I'll update the docs accordingly.
Ylechevallier, thanks for catching that, we've updated all of the docs to reflect the changes.
Since sslRootCAPath is not used on windows, as mentioned, docs should note how to achieve this using the depreciated settings:
caCertFile = cacert.pem
caPath = $SPLUNK_HOME\etc\auth
sslCertPath is deprecated in 6.5 and should be replaced by clientCert.
From outputs.conf.spec:
clientCert = <path>
* The full path to the client SSL certificate in PEM format.
* If (and only if) specified, this connection will use SSL.
* There is no default value.
sslCertPath = <path>
* DEPRECATED; use 'clientCert' instead.
The above example in this official documentation forwards encrypted traffic over TCP/9997. The examples in most unofficial documentation/guidance leave TCP/9997 for plaintext and specify TCP/9998 for TLS.
Just an observation that there's a mismatch.