The answer to my question comes from an article I found this afternoon and I completely understand what I was doing wrong before.
http://demarcsek92.blogspot.com/2014/05/mongodb-ssl-setup.html
I'll explain a little more because of the suggestion from Markus.
Originally I was generating client and server key/certification pairs from a root CA that I had created. I was concatenating (adding) the other certificates that I was making to the root CA and using this as the input for --sslCAFile. The issue I was creating was using my server.pem key/cert for each node and then trying to pass the client.pem file to the server for validation which I found out throws the generic "Self signed certificate" error. Apparently it happens whenever invalid certs/keys are passed to the server to create a connection.
(I'm going to gloss over how to make the server/client key/cert as it is in the article and I would like people to go there for more explanation as it is this gentleman's solution and not my own.)
Create server.key and server.crt
Use "type server.key server.crt > server.pem" (for Windows)
Create client.key and client.crt
Use "type client.key client.crt > client.pem"
For the server the setup will be:
--sslPEMKeyFile = server.pem
--sslCAFile = client.pem
For the client the setup will be:
--sslPEMKeyFile = client.pem
--sslCAFile = server.pem
This solution, as is, works for a single node and single client connection. I was able to trace the line with Wireshark and see that Mongo had stopped identifying itself and that when I drilled down into the packets using the Follow TCP Stream option the only information it was exposing was part of the subject used in creating my certificates (ok behavior).
Find "Client Hello" transmission from Mongo by:
Right-clicking on one of tranmission messages > Decode as... > Transport tab > SSL
On the "Client Hello" transmission from Mongo:
Right-click the packet > Follow TCP Stream > You should see the packet encrypted
NEXT STEP:
My next step is to figure out how to setup SSL certificates for a 3 node replica set. I'm still trying to wrap my head around creating certificates for each node and how they can all be linked so it will allow for each to trust each other and a client connection.
(I'm going to look into the Stack Exchange rules but I was just thinking about chaining to the next topic with a link in this one)
When you are using automation agent, configuration is done at OPS manager (or cloud front) and there is not much what you can do at actual machine. Yes, in this case, automation agents config file includes information of port and other parameters.
When you start locally installed mongod (f.ex. systemctl start mongod), it is set at (systemctl) mongod.service file that startup command is mongod -f /etc/mongod.conf, so config file is /etc/mongod.conf where all startup parameters has been defined.
Best Answer
I know it's an old question, but just in case this helps someone else who stumbles upon this page looking for something like I did:
The PEM file is there for the server to provide a way to prove its identity for any client that requests it. It will basically ensure a secure connection for any client. And in a production environment, there would be a proper certificate, instead of a self-signed one. If you notice, when you remove the
--sslAllowInvalidCertificatesflag from the connection string, you'll get the following error message for a self-signed certificate:The
--sslAllowInvalidCertificatesflag is given as a workaround for testing / development environments. Technically, the client could use it even when connecting to a production environment. But in that case, the loss is of the client only, as a rogue element could be posing as the server, and with this flag, the client wouldn't be able to verify the identity of the server. So, this flag should only be used when you are absolutely sure that you are connecting to the right server only. In your example, you are sure. But if you weren't, and you wanted to make sure that the server was really who it said it was, the PEM would come into the picture.