How to use REST API over port 8089 with the Splunk Web SSL certificate instead of the self-signed certificate?

[tweaktubbie]

Let me point out I've checked all the 8089 certificate questions on >answers, but have a slightly different question.
On my existing environments the request has come to serve access over port 8089. The https://internalsplunkurl:8089/services needs a valid certificate, and it is mentioned a lot the web.conf settings have to be put in stanza in the server.conf ssl.

First question that pops up: if changing the default certificate for server.conf, this will affect all local Splunk Universal Forwarder/agents that connect to your server?
They are likely not to be able to connect when the self-signed one is replaced? If this assumption is true, then all UF installations have to be changed - or there should be some way to create a kind of keystore which contains both selfsigned and 3rd party signed elements?

Second one that has not been answered clearly when looking at depricated stanza in other questions; how to go from the web.conf to server.conf, assuming you can as written use the same certificate/chain there for 8089?

In web.conf:

 [settings]
 enableSplunkWebSSL = 1 
 privKeyPath = /opt/splunk/etc/auth/SplunkWebPrivateKey.key
 caCertPath = /opt/splunk/etc/auth/cacert.pem

In server.conf:

 [sslConfig]
 enableSplunkdSSL = true
 sslRootCAPath = /opt/splunk/etc/auth/cacert.pem
 serverCert = /opt/splunk/etc/auth/servercert.pem

Which servercert.pem in server.conf (serverCert) has to be used? I'm missing out why the Web seems to need other/less info than the Server conf.

[jwelch_splunk · Accepted solution]

Question 1.

If you change the default cert for port 8089, this would not break the connectivity from a UF talking to your Splunk Instance for example if the instance is a Deployment Server. (Unless you did a more advanced SSL configuration E.G.
sslVerifyServerCert
sslCommonNameToCheck
ETC....

If you do change the default cert for 8089, this would also change the cert for kvstore, which is okay.

Your issue will be if you try and use sslRootCAPath, if you use this setting in server.conf, then this setting will over-ride all caCertFile / caCertPath / rootCA stanza's

So your inputs.conf would use this chain, your server.conf would use this chain and this would be fine because I assume that your new cert is what you want for both of those components. what would break is this:

[applicationsManagement]
allowInternetAccess = true
url = https://apps.splunk.com/api/apps
loginUrl = https://apps.splunk.com/api/account:login/
detailsUrl = https://apps.splunk.com/apps/id
updateHost = https://apps.splunk.com
updatePath = /api/apps:resolve/checkforupgrade
updateTimeout = 24h
sslVersions = tls1.2
caCertFile = $SPLUNK_HOME/etc/auth/appsCA.pem
sslVerifyServerCert = true
sslCommonNameToCheck = apps.splunk.com, cdn.apps.splunk.com
sslAltNameToCheck = splunkbase.splunk.com, apps.splunk.com, cdn.apps.splunk.com
cipherSuite = TLSv1+HIGH:@STRENGTH

Because applicationsManagement needs to point at /opt/splunk/etc/auth/appsCA.pem

So even though we say these settings are deprecated, at present you would still need to use them if you are replacing certs for 8089...

Example config:
web.conf
[settings]
enableSplunkWebSSL = 1
privKeyPath = /opt/splunk/etc/auth/SplunkWebPrivateKey.key <-- this file should only have the unencrypted key
serverCert = /opt/splunk/etc/auth/cacert.pem <-- This file should only have the SERVER CERT not the root/int cert

server.conf
[sslConfig]
caCertFile = $SPLUNK_HOME/etc/auth/mypki/CA_Cert.pem <-- This file should only have the INT and ROOT certs in that order if no INT exists then just the ROOT will be fine
serverCert = $SPLUNK_HOME/etc/auth/mypki/server_cert.pem <<-- This file would have Server Cert followed by Server Encrypted Key followed by INT Cert if one exists followed by Root Cert
sslPassword = whatever

inputs.conf
[SSL]
sslPassword = whatever
rootCA = $SPLUNK_HOME/etc/auth/mypki/CA_Cert.pem <-- This file should only have the INT and ROOT certs in that order if no INT exists then just the ROOT will be fine
serverCert = $SPLUNK_HOME/etc/auth/mypki/server_cert.pem <<-- This file would have Server Cert followed by Server Encrypted Key followed by INT Cert if one exists followed by Root Cert

The file names I used here are irrelevant, I would assume that you could put the right bits in each of these files. So now your web/inputs/8089/kvstore would all be using your custom certs. And your [applicationsManagment] would still be using the appsCA.pem

For the UF's themselves you could also uses the same certs for outputs.conf and 8089 on those if you wanted to. The advanced configs is where if you are not careful you can go south in a hurry.

[splunk24]

i am using splunk 6.4.7 version
client share some vulnerability for 8089 SSL Certificate Signed Using Weak Hashing Algorithm

i have got cert and key with me
please help me what need to be change in server.conf for 8089 port

[slicknetninja]

Hi John,

Are we able accomplish explicitly the title question (3rd party SSL cert with web.conf and server.conf) and not modify the inputs.conf and outputs.conf files across the board?

We currently have 6.4.1 running, and another team has an API (possibly Informatica) they want to use, but it is not able to use a self-signed certificate.

Thanks!
Jonathan

[responsys_cm]

John... thanks for a great reply! If using sslRootCAPath breaks the [applicationsManagement] stanza (I've seen this in real life), why is caCertFile deprecated? Following Splunk best practices is guaranteed to break its ability to see when new versions of Splunk or its apps are available and to install new apps via the GUI...

[jwelch_splunk]

Each component is self maintained.

Web has its own bits
main splunkd its own
inputs its own

So essentially you have three "ssl servers" each can have different configs. If you get stuck here, I would suggest you file a support case, so we know exactly what you are wanting to do.

John

[jwelch_splunk]

What version of Splunk are you using?

[tweaktubbie]

Version 6.5.1