How to establish trust for SSL certificates over LDAP (LDAPS)?

How to establish trust for SSL certificates over LDAP (LDAPS)?

I've combed through the documentation and google-fu'd to the best of my ability, but while there's an explicit means to "Accept Untrusted Certificates" there is no documentation (that I've found) on where to establish trust for SSL certificates for LDAP by MC.

The root certificate of the CA that signed our SSL certificate for LDAP is present in the certificates store (in windows) of the machine that MC is installed on. I have also been in the MCAdmin Utility and perused the Certificates section, but none of the sub-sections there appear to have any indication that they would be related to establishing trust for LDAPS.

Any assistance is appreciated.

  • 07 July 2018
  • SOTI MobiControl
  • 7 Answers
  • 0 Upvote
  • 1 Follower
  • 1.9K Views
    • 7 Answers
    • 0 Upvote
    • 1 Follower

7 Answers

Order By:   Standard | Newest | Votes
Raymond Chan | posted this 08 July 2018

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.

 

 

 

  • 0
  • 0
Sean Groomes | posted this 08 July 2018

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.

  • 0
  • 0
Support Staff | posted this 10 July 2018

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 |

 

 

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

  • 0
  • 0
Sean Groomes | posted this 11 July 2018

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.

  • 0
  • 0
Sean Groomes | posted this 11 July 2018

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.

  • 0
  • 0
Support Staff | posted this 11 July 2018

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 |

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

  • 1
  • 0
Sean Groomes | posted this 11 July 2018

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.



  • 0
  • 1

Give us your feedback
Give us your feedback
Feedback