Splunk TCP-SSL Input Not Enforcing Client Certificate Authentication

Applicability

Description

When configuring a TCP-SSL input to receive encrypted, unparsed data from a third-party system, the requireClientCert attribute enables client certificate authentication.

If the input does not enforce client certificate authentication, connections can behave differently from the expected mutual TLS configuration.

This article describes how to troubleshoot and validate client certificate authentication on a TCP-SSL input.

Investigation

• Verified the effective [tcp-ssl:2235] configuration using btool and confirmed that requireClientCert = true was correctly configured in the path /opt/splunk/etc/apps/<app_name>/local/inputs.conf
  
  
• Reviewed the TLS configuration in /opt/splunk/etc/system/local/server.conf and the port-specific server certificate to verify the existing certificate configuration.
  
  
• Reviewed the Splunk configuration documentation and confirmed that requireClientCert is supported for TCP-SSL inputs.
  
  
• Performed a controlled Splunk restart and repeated the TLS validation tests from an external host to eliminate potential discrepancies associated with localhost testing.
  
  
• Configured an additional TCP-SSL listener on port 2234 without client certificate authentication to compare its TLS handshake behaviour with port 2235.
  
  
• Observed that port 2235 requested a client certificate, rejected connections without a certificate and rejected certificates issued by untrusted CAs. The comparison listener on port 2234 did not request a client certificate.

Resolution

• Retained the existing [tcp-ssl:2235] stanza in /opt/splunk/etc/apps/<app_name>/local/inputs.conf with requireClientCert = true and the dedicated Company B server certificate.
  
  
• Retained the existing [sslConfig] configuration in /opt/splunk/etc/system/local/server.conf, including the configured CA bundle, without modifying the standard Splunk TLS configuration.
  
  
• Performed a controlled Splunk restart to reload the existing configuration.
  
  
• Successfully validated mutual TLS enforcement on port 2235 using external TLS handshake tests. Confirmed that connections without a client certificate and connections with certificates issued by untrusted CAs were rejected. 
  
  
• Verified that the separate TCP-SSL listener on port 2234 continued to operate without client certificate authentication, as intended.

 The issue was resolved by reloading the existing configuration and validating the TLS handshake from an external host. No changes to the input type or external TLS proxies were required.

Related Links

inputs.conf