If I configure a third-party cert on the DS for ports 8191 and 8089, do I need to make any changes to the UFs?

[StephenD1]

I'm trying to replace the default SSL certs on the deployment server with third-party certs but I'm confused about what it entails. I don't know much about TLS certs, mostly just the basics. I'm following these documents for the deployment server-to-client:
https://docs.splunk.com/Documentation/Splunk/latest/Security/StepstoSecuringSplunkwithTLS
https://docs.splunk.com/Documentation/Splunk/latest/Security/ConfigTLScertsS2S. 

If I make the changes on the deployment server to point to the third-party cert, do I also need to change the cert on the UFs to keep communicating on port 8089?

[livehybrid · Accepted solution]

Hi @StephenD1 

You will need to ensure that the UFs trust the certificate that the DS uses on port 8089. 

You can specify a custom CA to be used for the UFs in the deploymentclient.conf under the caCertFile key in the [deployment-client] stanza. By default this uses the CA specified in server.conf but can be overridden for your DS. For more info check the docs at https://docs.splunk.com/Documentation/Splunk/latest/Admin/Deploymentclientconf#:~:text=normally.%0A*...

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[StephenD1]

Ok, so just to summarize to make sure I understand, I would create a custom cert (either self-signed or third-party) and configure the DS to use that cert per the links I had above. Then I would configure the UFs to trust that cert's CA in their deploymentclient.conf file. 

If I understand correctly, I'm only creating the one custom cert for the deployment server itself. The UFs don't need their own cert, they only need to trust the CA for that cert I created for the DS. Is that correct? 

(Sorry for the pedantry, I'm just unsure if I fully understand the cert process in general and don't want to assume I understand then break my environment)

[PickleRick]

TLS can be sensitive to errors and it's relatively easy to break your environment so I'd advise you to do some lab work (not necessarily with Splunk; apache httpd for example is a very well docummented solution you can use to get experience with real-world third-party CA - you can use Let's Encrypt for free).

But back to your question - as a rule of thumb, the side which identity you need to verify must use a certificate trusted by the other side. So typically - like with most of the HTTPS servers over the internet - the server presents a certificate issued by a CA that the client trusts. That's the basic minimal setup which allows the client to be sure that the server is who it claims to be and then allows it to negotiate a protected encrypted connection within which it can, for example, authenticate itself using normal HTTP means.

This is the way it works normally between your browser and most internet services - your browser has a list of trusted RootCAs. The server you're trying to connect to presents a certificate with certificate chain tracing back to a RootCA your browser trusts. The browser checks if the certificate is valid, matches the server you wanted to connect to and the purpose for which the certificate was issued (so you can't just set up a www server with a certificate meant for S/MIME mail encryption). Your browser negotiates an encrypted connection with the server and within this connection, since you can now trust that the server is who it claims to be, you authenticate yourself using login/password or whatever other method you use because you know that you're talking to a known party over a secure channel.

That's a typical use case and it matches the typical use case with UF as a client (both as a client for DS as well as a client connecting to the indexer/HF). You need to have a certificate issued by a trusted CA (or having a certification chain back to trusted CA) on the server (DS, idx and so on) and have the UF trust the CA certificate. In this case all UFs just need to have this one CA certificate configured as a trusted CA.

But you can also if needed configure client's authentication. In such case each UF would have its own certificate which in this case would need to be issued by a CA trusted by the server. In this scenario, typically referred to as mTLS or mutual authentication, each side verifies the identity of the other endpoint so each unique subject (in our case each UF) would require a separate individual cert.

This scenario is however difficult to manage without a lot of administrative overhead (just tracking expiration dates of dozens of certs is enough of a headache, not mentioning renewing them and installing) so it's not commonly used. But it's possible.

[StephenD1]

Thank you both. This was really helpful.