Getting Data In

Could someone help clarify Splunk documentation accuracy around forwarder SSL configuration?

shocko
Contributor

Using Splunk Enterprise 8.2.4 on Windows and trying to configure my forwarders to use SSL to forward events to my indexers. Client certificate verification is not enabled on the indexer. Reading the guide here it states some config aspects that don't seem to be true from testing:

sslPassword = <password>
* The password associated with the Certificate Authority certificate (CAcert).

Is this  not the password for the client cert (server.pem by default) rather than CACert? Also, is states:

useSSL = <true|false|legacy>
* Whether or not the forwarder uses SSL to connect to the receiver, or relies
  on the 'clientCert' setting to be active for SSL connections.
* You do not need to set 'clientCert' if 'requireClientCert' is set to
  "false" on the receiver.

This appears to indicate that you can use SSL without a client certificate (which would be great!). However, if I simply add  useSSL=true to my forwarder outputs.conf the SSL connection does not come up and the following is showing splunkd.log indicating it is looking for a client certificate file:

03-30-2022 23:39:47.933 +0100 ERROR SSLCommon [31888 parsing] - Can't read certificate file errno=33558528 error:02001000:system library:fopen:system library

My outputs.conf is as follows:

[tcpout:test-ssl-1]
disabled = 0
server = indexer1.mydomain.com:9998
useSSL = true
useClientSSLCompression = true
sslVerifyServerCert = false

This outputs.conf does work:

[tcpout:test-ssl-1]
disabled = 0
server = indexer1.mydomain.com:9998
useSSL = true
useClientSSLCompression = true
sslVerifyServerCert = false
sslCommonNameToCheck = indexer1
sslAltNameToCheck = indexer1.mydomain.com
sslRootCAPath = C:\Program Files\SplunkUniversalForwarder\etc\auth\MyPKIChain.pem

 I have no idea why the 2nd config works! sslVerifyServerCert  is false. 

 

Labels (1)
Tags (1)
0 Karma

moliminous
Path Finder

I believe this is another case of unclear documentation.

The useSSL setting, as seen in the doc snippet you posted, does not say you don't need a cert, it says you don't need to set clientCert on the forwarder if the receiver has requireClientCert = false.

In other words, the 'useSSL' setting on the forwarder is telling that forwarder to use TLS authentication, which is different than just encrypting your logs with TLS, which uses the TLS cert from the receiver.

If you wish to encrypt your logs but don't need the receiver to require client TLS certs to authenticate, you don't need the useSSL=true setting.

The other settings you listed such as check CN and SAN that the receiver cert matches the indexer you listed, are not required since you told the client to not require a server cert when connecting.

So there are 3 related but distinct TLS topics here: log encryption using TLS, the forwarder authenticating the server using TLS, and the receiver authenticating the forwarder using TLS.

The .conf.spec docs are not clear about which settings are for which TLS function, making it confusing.

useSSL = <true|false|legacy>
* Whether or not the forwarder uses SSL to connect to the receiver, or relies
  on the 'clientCert' setting to be active for SSL connections.
* You do not need to set 'clientCert' if 'requireClientCert' is set to
  "false" on the receiver.

 

0 Karma

psharkey
Explorer

I faced a similar situation. However, I only needed to include the sslRootCAPath directive. Neither of the NameToCheck directives were necessary.

I ended up deploying a PKIChain.pem file in a different App which also included a server.conf file with an [sslConfig] stanza like this:

[sslConfig]
sslRootCAPath = $SPLUNK_HOME/etc/apps/<App>/default/PKIChain.pem

splunky147
Splunk Employee
Splunk Employee

@psharkey Could you please clarify why we need `sslRootCAPath` here? The docs are not clear enough.

0 Karma
Get Updates on the Splunk Community!

Say goodbye to manually analyzing phishing and malware threats with Splunk Attack ...

In today’s evolving threat landscape, we understand you’re constantly bombarded with phishing and malware ...

AppDynamics is now part of Splunk Ideas

Hello Splunkers, We have exciting news for you! AppDynamics has been added to the Splunk Ideas Portal. Which ...

Advanced Splunk Data Management Strategies

Join us on Wednesday, May 14, 2025, at 11 AM PDT / 2 PM EDT for an exclusive Tech Talk that delves into ...