Using existing Splunkweb certificate to secure an addtional port

[ptrsnk]

We have an existing Splunk 9.1.3 Enterprise environment and run Splunkweb at port 8000 using an outside CA signed certificate for https.  A partner wants to stream syslog data to our Splunk using a secure connection.  I added the following to inputs.conf located in system/local.

[tcp-ssl:6514]
sourcetype = syslog
index=syslog
disabled = 0

[SSL]
privKeyPath = /opt/splunk/etc/auth/splunkweb/2024/splprkey.key
serverCert = /opt/splunk/etc/auth/splunkweb/2024/prcert.pem
requireClientCert = false

After a restart ,I used openssl to test the connection.  Port 8000 worked normally as expected; the certificate was returned and I could see the TLS negotiation in Wireshark   The openssl  connection to port 6154 did not work .  A connection was made and openssl did send a "Client Hello" which was visible in Wireshark,  but other than an ACK the Splunk server never sent anything further.

Based on an article I read, I also copied the certificate path to the server.conf file, but that didn't change anything.  What am I missing? Is it incorrect to assume the same cert could be used for different ports?

Any assistance appreciated!

Thanks,

[livehybrid]

Its also worth mentioning that the client might need additional configuration to validate the commonName if the DNS name you are connecting with is not the same as the common name on the certificate.

@isoutamo The lantern page (https://lantern.splunk.com/Splunk_Platform/Product_Tips/Administration/Securing_the_Splunk_platform_...) is very useful, Ive got that bookmarked now, thanks 🙂

The leaf cert that is being used for the web SSL should be sufficient for the TCP Input cert as it is pretty much serving the same purpose (a server cert). Interestingly I have definitely been able to use a server cert in the past as a client certificate, although technically speaking I dont think that should be possible as the server should be checking for "Client Authentication" (OID 1.3.6.1.5.5.7.3.2) attributes.

Anyway, @ptrsnk please keep us posted 🙂 

Will

[ptrsnk]

It looks like the certificate is good for either client or server authentication.

[isoutamo]

You could create combined server/client cert and use it in both environments. Another excellent conf presentation about tls cert https://conf.splunk.com/files/2023/slides/SEC1936B.pdf

Also this is nice tool for manage certs https://easy-rsa.readthedocs.io/en/latest/

[ptrsnk]

Hello isoutamo;  Thank you for the links; a lot of useful info. I am not an expert in the area of PKI Certificates etc.  I  have a basic understanding only.  The term leaf certificate was new to me.

Ptrsnk

[isoutamo]

Hi

there are different cert types which contains different options. Basically it depends which kind of web server certificate you have, can you use it also for server’s management cert. If it’s pure client certificate (web can be that) then it didn’t work as server needs server certificate. You can read more e.g. from https://lantern.splunk.com/Splunk_Platform/Product_Tips/Administration/Securing_the_Splunk_platform_...

——

Leaf (client/server) certificates

Leaf means that the certificate is unable to sign any additional certificates. They are often referred to as client or server certificates because that’s generally what they represent, but these are not technical TLS terms.

• Splunk platform systems use server certificates, meaning the certificate should represent the system(s) in the Subject Alternative Name (SAN) line and Common Name (CN) value. Splunk platform allows wildcard CN/SANs to be used. You can also put multiple hosts in the SAN, but this can become difficult to manage or update compared to a wildcard.
• Universal forwarders (or web browsers, if desired) use client certificates. These are called client certificates because they don’t need to represent (the CN/SAN) the system they’re installed on. They only need to be signed by an issuer that the Splunk platform server trusts. You might hear these referred to as forwarder certificates in the Splunk ecosystem.
• You’ll also often hear the term “(full) certificate chain” when reading about TLS. A certificate chain is a leaf certificate that has the proper issuer certificates under it in a single file. In Splunk we automatically create the chain by using the client/serverCert and sslRootCAPath values automatically, so you should not create a "full chain certificate". You should place the server/client certificate and private key in one file, and all of your issuer certificates in another file.
  
  

r. Ismo

[livehybrid]

Hi @ptrsnk 

First of all, I dont think the "privKeyPath" key is a valid key in inputs.conf. Infact you should just be using serverCert and giving the path to your full certificate chain (in PEM format), including key and CA.

yourCert.pem
<YourSSLCert>
<YourPrivateKey>
<YourCertCA>

You will also need to specify sslPassword if you are using an encrypted private key for your cert.

For more information check out the inputs.conf spec page at https://docs.splunk.com/Documentation/Splunk/9.4.0/Admin/Inputsconf

There is also another useful answer at https://community.splunk.com/t5/Security/TCP-Data-Input-and-SSL/m-p/483077 with more context and suggestions.

Please let me know how you get on and consider adding karma to this or any other answer if it has helped.
Regards

Will

[ptrsnk]

I took a look at our existing servercert .pem file in vi. It did not contain the private key; it did include the root and intermediate certs   I copied the contents of our private key .pem file to the location you suggested.

mainCert/private key/intermediate cert/root cert

I saved the new .pem file with a new name and put it in a new location under /opt/splunk/etc/auth/newssl and updated the inputs.conf file (below) at system/local.

disabled = false
connection_host=ip
index =main

[tcp:514]
disabled = false
connection_host=ip
index =main

[udp://514]
index = main
sourcetype=syslog
disabled = no

[tcp-ssl:6514]
sourcetype = syslog
index=syslog
disabled = 0

[sslConfig]
sslPassword = $7$pZd1k8bLJzFgGDno3jU7PQ4lAIFBoUbdhOAaFDZojyT1H6DGb5RdRA==
serverCert = /opt/splunk/etc/auth/newssl/prcertkey.pem
requireClientCert = false

However, when testing the connection with openssl,  I get the same behavior, a tcp connection is made, but no certificate activity.  I get a CONNECTED(00000148) message which hasn't led me to anything specific.

I'm still missing something.

peter

[ptrsnk]

Thank you  livehybrid,

I will tryout your suggestions and respond back to you.