Secure access to your Splunk server with SSL
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Contents
Secure access to your Splunk server with SSL
The Splunk management port (default 8089) supports either SSL or plain text connections. SSL is turned on by default for communications among Splunk servers. Distributed search will often perform better with SSL enabled because of its built-in data compression.
To make changes to SSL settings, edit server.conf.
Important: If you are using Firefox 3, enabling SSL for a Splunk deployment may result in an "invalid security exception" being displayed in the browser. Refer to this workaround documentation for more information.
Note: This only enables SSL for Splunk's back-end communication. To turn on SSL for the browser, see "Secure access to Splunk with HTTPS".
Working with SSL settings
When the Splunk server is turned on for the first time, the server generates a certificate for that instance. This certificate is stored in the $SPLUNK_HOME/etc/auth/ directory by default.
Change SSL settings by editing $SPLUNK_HOME/etc/system/local/server.conf. Edit this file in $SPLUNK_HOME/etc/system/local/, or your own custom application directory in $SPLUNK_HOME/etc/apps/. For more information on configuration files in general, see how configuration files work.
[sslConfig] enableSplunkdSSL = true sslKeysfile = server.pem sslKeysfilePassword = password caCertFile = cacert.pem caPath = $SPLUNK_HOME/etc/auth certCreateScript = $SPLUNK_HOME/bin/genSignedServerCert.py
-
enableSplunkdSSL= Setting this boolean key totrueenables SSL in Splunk. -
sslKeysfile= Certificate for this Splunk instance (created on Splunk start-up by default - if thecertCreateScripttag is present).
Note: The path to the keyfile is relative to the caPath setting. If your keyfile is kept outside $SPLUNK_HOME, you must specify a full (absolute) path outside of $SPLUNK_HOME to reach it.
-
sslKeysfilePassword= Password for the pem file store, is set topasswordby default. -
caCertFile= This is the name of the certificate authority file. -
caPath= Path where the Splunk certificates are stored. Default is$SPLUNK_HOME/etc/auth. -
certCreateScript= Script for creating & signing server certificates.
With the default script enabled, on startup, Splunk will generate a certificate in the caPath directory.
Deactivate SSL
To deactivate SSL, simply set enableSplunkdSSL to FALSE. This will disable SSL.
Note: Running splunkd without SSL is not generally recommended. Distributed search will often perform better with SSL enabled.
Disable SSLv2
To disable SSLv2 and tell the HTTP server to only accept connections from SSLv3 clients, include the supportSSLV3Only attribute and set it to TRUE. By default, this setting is FALSE.
Generate signed certificates
By default, all Splunk servers use the same self-signed certificate. The certificate's public and private keys are distributed with Splunk. This allows Splunk instances to connect to each other out of the box and lets you regenerate and sign your server certificates.
You can change this default behavior. There are scripts located in $SPLUNK_HOME/bin that you can use to generate and self-sign your server certificates.
genRootCA.sh | Run this script when you want to regenerate the certificates Splunk uses. It generates cacerts.pem (public key) and ca.pem (public/private password protected PEM). When you run it, it checks to see if certs are already in place, and if they are, prompts you to overwrite them. It then wraps these files into an X509-formatted cert. Distribute cacerts.pem to clients as desired and keep ca.pem in a secure location.
|
genSignedServerCert.sh | This shell script is a wrapper for the Python script that Splunk runs to generate certificates when you start it for the first time. This script creates a CSR (certificate signing request), self-signs it, and outputs a signed server.pem that you can distribute to your Splunk servers.
|
Generate a CSR (Certificate Signing Request)
If your organization requires that your Splunk deployment use a certificate signed by an external CA, you can use the following procedure to generate the CSR to send to the CA:
openssl req -new -key [certificate name].pem -out [certificate name].csr
You are prompted for the following X.509 attributes of the certificate:
- Country Name: Use the two-letter code without punctuation for country, for example: US or GB.
- State or Province: Spell out the state completely; do not abbreviate the state or province name, for example: California
- Locality or City: The Locality is the city or town name, for example: Oakland. Do not abbreviate. For example: Los Angeles, not LA, Saint Louis, not St. Louis.
- Company: If your company or department contains an &, @, or any other non-alphanumeric symbol that requires you to use the shift key, you must spell out the symbol or omit it. For example, Fflanda & Rhallen Corporation would be Fflanda Rhallen Corporation or Fflanda and Rhallen Corporation.
- Organizational Unit: This field is optional; but you can specify it to help identify certificates registered to an organization. The Organizational Unit (OU) field is the name of the department or organization unit making the request. To skip the OU field, press Enter.
- Common Name: The Common Name is the Host + Domain Name, for example www.company.com or company.com. This must match the host name of the server where you intend to deploy the certificate exactly.
This creates a private key ([certificate name].key), which is stored locally on your server, and a CSR ([certificate name].csr), which contains the public key associated with the private key. You can then use this information to request a signed certificate from an external CA.
To copy and paste the information into your CA's enrollment form, open the .csr file in a text editor and save it as a .txt file.
Note: Do not use Microsoft Word; it can insert extra hidden characters that alter the contents of the CSR.
This documentation applies to the following versions of Splunk: 4.0 , 4.0.1 , 4.0.2 , 4.0.3 , 4.0.4 , 4.0.5 , 4.0.6 , 4.0.7 , 4.0.8 , 4.0.9 , 4.0.10 , 4.0.11 View the Article History for its revisions.