Mongotools's –sslPEMKeyFile parameter takes in a .pem file that contains both the TLS/SSL certificate and key. 

Since tool's SSL/TLS code is copied from Go driver, the current implementation only parses the last certificate inside the pem file.

So if a pem file is structed such as 

-----BEGIN RSA PRIVATE KEY-----
(Your Private Key: your_domain_name.key)
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: clientCert.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE----- 

The tool will fail to start up due to failed private key, certificate pair match since it only loads the last cert (root cert).

This is a discrepancy with Mongoshell behavior, which only loads the first certificate inside the pem file. It is also the default behavior for many libraries including Go-language TLS lib.  (I took a look at Mongo agent code and think it only loads the first certificate as well). 

So here are the questions we need to answer in this ticket:

• How likely the user will have multiple certificates inside a client pem file. This decides if we need to make the change or educate users to only put one certificate inside the pem file.
• Should we follow the Mongo Shell behavior to load only the first certificate? This might break the existing Tools client workflow.
• There is another option which is how I planned to solve it at the first place. We can load all the certificates inside the pem file and use the private key inside to find the matching one regardless of the sequence. 

Keep in mind, we are asked to keep the Tool's TLS logic in sync with Go driver, so whichever change we make in tools will be copied to Go driver as well. We need to justify our decision to the driver team as well.