In most Splunk setups you have 2-3 SSL certificates in use:
$SPLUNK_HOME/etc/auth/splunkweb/.pemfor SplunkWeb, typically 8443
$SPLUNK_HOME/etc/auth/server.pemSplunk’s management port, typically 8089
- A certificate for 9997
Typically it doesn’t matter that there are so many certificates; as long as the forwarders know what certificate to expect when connecting to an indexer on 9997 and splunk internally can validate the cert on 8089, there is no reason for them to be signed by a 3rd party CA.
For the SplunkWeb certificate, a user using a browser will be connecting; if you have a private CA whose certificate if installed in all of your company’s browsers then great, use it. For our purposes, we have standardized on a 3rd party CA that’s widely trusted so we have a certificate signed by them.
Desire for Fewer Certificates
Now comes the fun part, I’m managing two SSL certs on all of our Splunk infrastructure servers: SplunkWeb and Splunkd certs on searchheads and Data (9997) and Splunkd on the indexers. Being the lazy person that I am, I’d love to get that down to one cert to make renewals easier.
Another benefit of using 3rd party CA’s is our risk people want every certificate signed by a 3rd party CA. There’s nothing magical about a 3rd party CA so that requirements doesn’t increase security in anyway. Their desire means I have to fill out an exception for every self-signed or internally signed certificate, so switching to a 3rd party signed certificate makes my life easier.
Combine key and cert into one
$SPLUNK_HOME/etc/auth/splunkweb, combine the key and certificate into one file (e.g.
cd /opt/splunk/etc/auth/splunkweb && cat server.key server.pem > ../server.pem )
- splunkweb/server.key is the private key
- splunkweb/server.pem is the certificate chain (certificate and any intermediates)
privKeyPath = etc/auth/server.pem
caCertPath = etc/auth/server.pem