License manager / slave certificates

[splunkreal]

Hello,
Does Splunk license slave node with default certificates can communicate with license manager that has custom CA on management port?

Is there any ssl verification?

Thanks.

[splunkreal]

No it's by default so sslVerifyServerCert=false.

[richgalloway · Accepted solution]

If HTTPS is used and sslVerifyServerCert is set then both sides of the connection must use the same certificate.  See https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.2/secure-splunk-... and https://splunk.my.site.com/customer/s/article/Where-are-SSL-Configuration-Files-located-How-to-confi... for details.

[PickleRick]

Let me clarify it a bit.

We have side A and side B of a TLS connection. When side A initiates a connection to side B (let's say a UF connects to an indexer or an indexer connects to the license master), side B presents a certificate. Normally this would be a certificate for a subject B (certBsub) issued by some intermediate CA (certinterCA), which in turn is normally issued by a root CA (with a certRootCA)- that's a most typical scenario. There might be more intermediate intermediate CAs in chain (certBsub<-certinter1CA<-cetinter2CA<-...<-certRootCA), but that's fairly rare. There might be a certificate directly issued by rootCA (certBsub<-rootCA) but that's also rare since it involves rootCA in operational work which is not very secure.

So the proper setup of certificates in such environment would be like this:

- side B should have and present to the clients when being connected to a certificate chain consisting of its own subject certificate (certBsub) and intermediate certificates which were used to issue that certificate. Without the rootCA certificate (in practice it's often also presented but it's not needed there)

- side A needs to know only the rootCA certificate to be able to verify the whole path of certification from its trusted root to the subject certificate.

So the sides do not actually share any certificates. They rely on the fact that side B has a certificate which has been issued by a CA which is trusted by sideA.

If you also verify the client, another half of the mechanism works the other way around - apart from the client verifying the server as described above, the client on connection presents its own subject certificate along with possible certification chain up to but not including the rootCA and the server verifies the certification trust with a rootCA certificate it knows. It doesn't mean though that those rootCAs must be the same!