Managed to solve my problem. The answer to my question is MobiControl does rely on the built-in windows certificate services. Turns out the version of the Root certificate that was present in the Trusted Root store was an outdated Root certificate. After updating this it works as I anticipated. Ultimately I was looking for confirmation in the forums that MC was using Windows instead of JRE or some other service to manage certificates, since it looked like the Root certificate that was in the store was being ignored.

I think you just need to use Microsoft Management Console (MMC, by running "mmc" in Command shell) on your MobiControl server to import both the CA root certificate and the SSL certificate associated with the LDAPS port (636 by default).

Then add your new LDAP/AD connection in a MobiControl Web Console,  select port (636 by default) and check SSL option, and other required settings.  Then, check and see if your MobiControl server can get any AD/LDAP information (e.g. user, user group, etc.)  and display them on your web console if you configure any feature that needs such AD/LDAP information.

I'm sure Soti support team active in this forum will correct/supplement my reply if they find anything inaccurate or missing in this post.

Shouldn't need to import the SSL certificate itself. Since MC trust the RootCA then it should trust any certificates issued by valid subordinate as well. I'm certain the certificate chain is accessible as well.

Hi Sean, 

Before I can provide you with an answer, can you tell me a bit more about what your end goal is exactly in MobiControl?  

I understand that you are looking to "establish trust for SSL certificates over LDAP" but have you tried to configure LDAP in the console and received an Error?

We are also working on improving the helpfile and this will assist us in understanding it's shortcomings, if any.

Thanks,

Technical Support | SOTI Inc. |1.905.624.9828 | support@soti.net | soti.net |

The end goal is Secure LDAP (LDAPS) that is done without bypassing the security mechanism. Yes, I have tried to configure it in the LDAP console and the connection fails if the "Accept Untrusted Certificates" is unchecked. Call me cautious, but I do not want to bypass this check. I'm simply looking for a way to have MobiControl trust the Certificate chain.

Typically this is done by importing a Root Certificate into a trust store, which varies wildly by implementation. I'm simply looking for instructions on how this is done for MobiControl. It isn't documented anywhere I can find.

Hi Sean, 

Ultimately I was looking for confirmation in the forums that MC was using Windows instead of JRE or some other service to manage certificates, since it looked like the Root certificate that was in the store was being ignored.

Thanks for the update and the overall bigger picture. This was the information I was looking for, as you are correct we are currently in the process of improving documentation where necessary and I was looking to see your use case warranted this. 

It's hard to diagnose an expired certificate without visual confirmation and/or logs.   Since you have been able to resolve this I will include a link where certificate renewal information is located and go ahead and mark you post as solutioned.

http://www.soti.net/mc/help/v13/en/default.htm#Setup/Root-Certificate-Renewal.htm?Highlight=certificate

Cheers!

Technical Support | SOTI Inc. |1.905.624.9828 | support@soti.net | soti.net |

Ah, but you see the document you link actually has nothing to do with the SSL certificate presented during the LDAPS handshake. So there would be no visual feedback there to indicate that the SSL certificate was broken/expired. In my case the certificate was't "expired", but rather the Certificate was an older unexpired version with a different signature. While still valid, it was not the one that was used to sign the SSL certificate my Active Directory server presents.

I would say your documentation at minimum should include that it uses the builtin Windows Certificate store. It would've helped me troubleshoot it a little faster. By now google probably has cached this page though, which will probably be good enough to assist the next person who has a similar question.