
Secure deployment servers and clients using certificate authentication
There are certain situations where you might need to use certificate authentication in certain distributed configurations like deployment servers and clients. An example situation is when you send sensitive server configuration data to a variety of locations that are outside of your protected network through your firewall. You can manually configure each deployment client to communicate with your deployment server.
It's not possible for a deployment server to send certificates to deployment clients, even in an app. You must configure certificates on each deployment client separately.
- Create or obtain one or more certificates that use the same root certificate authority (CA). For the procedure, including instructions on how to create the certificate authority certificate, see the "Secure Splunk platform communications with Transport Layer Security certificates" chapter.
- Use file management utilities to distribute the certificates to your deployment server and deployment clients.
You might want to make a separate directory within each Splunk Enterprise instance to store the certificates, for example, you could put the certificates in the $SPLUNK_HOME/etc/auth/DScerts directory.
- On each deployment server, do the following:
- Using a text editor, open the
$SPLUNK_HOME/etc/system/local/server.conf
configuration file for editing. - In the file, provide the location of your certificates.
[sslConfig] caCertFile = <full path to the certificate authority certificate> # While this setting is deprecated, you can use # it to reference the certificate authority certificate. Otherwise, # use the 'sslRootCAPath' setting instead. sslVersions = tls1.2 sslPassword = password # The password for the server certificate, if it exists.
- Save the file and close it.
- Using a text editor, open the
- On each deployment client, do the following:
- Edit the
$SPLUNK_HOME/etc/system/local/server.conf
configuration file to provide the location of your certificates.
[sslConfig] enableSplunkdSSL = true sslVersions = tls1.2 serverCert = <full path to the server certificate file> # Replace the default certificate with your own certificate # file, in Privacy-Enhanced Mail (PEM) format. caCertFile = <full path to the certificate authority certificate> # While this setting is deprecated, it still works and you can use # it to reference the certificate authority certificate. Otherwise, # use the 'sslRootCAPath' setting sslPassword = password # The password for the server certificate, if it exists. sslVerifyServerCert = true # Require that the server certificate contains one of the host names that you # specify in the 'sslCommonNametoCheck' or 'sslAltNametoCheck' settings. # If the certificate contains a host name that is in either of these settings, the # connection succeeds. sslCommonNametoCheck = <host name of the deployment server>
- Add the
requireClientCert
setting under the[sslConfig]
stanza to force the deployment clients to authenticate using your certificates:
[sslConfig] ... requireClientCert = true
- Save the server.conf file and close it.
- Edit the
$SPLUNK_HOME/etc/system/local/web.conf
configuration file so that the deployment client presents a certificate signed by the same root CA so that Splunk Web can connect to the server.
The following is an example of an edited settings stanza:
[settings] enableSplunkWebSSL = true privKeyPath = etc/auth/splunkweb/mySplunkWebPrivateKey.key serverCert = etc/auth/splunkweb/mySplunkWebCertificate.pem cipherSuite = <your chosen cipher suite (optional)>
The
requireClientCert
setting has a default value of "false". If you give it a value oftrue
to force Splunk Enterprise to check your client certificates, Splunk Enterprise will also check Splunk Web and the CLI for certificates. - Edit the
PREVIOUS Securing distributed search heads and peers |
NEXT Configure communication and bundle download authentication for deployment servers and clients |
This documentation applies to the following versions of Splunk® Enterprise: 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.1.0, 9.1.1, 9.1.2
Feedback submitted, thanks!