This article is meant for many uses cases. Not just singular. It should give the good understanding about how certificates work overall. Just like sslRootCAPath is meant to TRUST the certificates coming from other instances. I will give you some examples: - License Manager connection - Heavy forwarder to Deployment Server connection - Cluster Manager connection. etc. Please give it a whole thorough read once again top to bottom to understand the inner workings of Certificates. And then apply it accordingly to your specific need, architecture and deployment. P.s. server.pem is something I discuss in this article too. As the Identity Certificate. What you say is true "I have the root CA so I would cat that with the "server.pem" cert and that would be it?" but that would be just for the indeitity cert itself. Once you get into the weeds of who sends certificate to who. As in e.g. -> - When indexers connect to License manager they would get certificate from LM being server certificate. - But then You can also expand that knowledge now. And apply that to the Universal Forwarder. There you have something you can Client Cert. Which also would need to be trusted on the other side. - OR forwarder connection to Deployment Server. Deployment Server needs to have server cert right? But then Universal Forwarders need to trust it too IF you do verify server cert there. And the list goes on. TL:DR Server.pem -> in most cases it's just the: - Public key inside certificate of the server - Private key corresponding to the public key above - Certificate of whoever issued it. sslRootCAPath -> Can be any number of certificates depending on the type of connections you use it for. And the number of different CAs you might have. You might be a middle man with several customers connecting to you each using their own certs and you need them trusted. Hope that makes more sense now.
... View more