Printout Header
LEX RSS Feed

LEX Online Manual Content

LDAPS / LDAP over SSL

LDAP connections can be established in an SSL session so that all data that is sent between the LDAP client and LDAP server is encrypted on the wire. This approach has several different labels, which are more or less synonyms:

  • LDAP over SSL
  • LDAP over TLS
  • LDAPS
  • LDAP/SSL
  • LDAP/TLS
  • Secure LDAP

All modern LDAP servers should be able to establish an SSL connection with their clients. There might be certain prerequisites (on the server as much as on the client), almost all of them have to do with certificates.

Such LDAP connections with SSL use the communication port TCP 636 by default, but there could be any other ports used for this, according to the server's configuration.

SSL is the Secure Socket Layer and can protect not only HTTP session for web browser, but also a lot of other communications protocols - including LDAP. TLS is the Transport Layer Security - this is kind of a modern version of SSL. We will use the term 'SSL' in this manual whenever we refer to this technique.


Configuring an SSL session to an LDAP server


To configure an LDAP session to use SSL, just activate the SSL checkbox in the LDAP Connection dialog:

Configuring SSL

If you do this, the LDAP communication port is changed automatically to 636. But as we mentioned above, you can change this port to any other valid TCP port number, according to the configuration of your LDAP server.

If you run an SSL session, there is an indication symbol for this in the right bottom corner of the status bar. You can double click on the symbol to display the server certificate:

Indication of an valid SSL certificate in the status bar

If the server does not support SSL, you get an 'LDAP server unavailable' error message.


SSL Certificate check


The simplest scenario for an SSL session is that the identity of the server is proven to the client, but not vice versa. The server proves the identity to the client with a certificate which can be checked by the client. Based on this, the data encryption can be set up by the client and the server:

SSL session layout

There are three main criteria for the client to check the validity of the certificate:

  • There is the network name of the server included with the certificate. In the certificate, this name is called the common name. The clients normally accepts only certificates with names that are 100% identical to the name/address which was used on the client to establish the connection.

  • There is a validity time period in the certificate which can be checked by the client.

  • Certificates are issued by so-called certificate authorities (CAs). The issuing CA (or one of it's parent CAs) has to be in the client's list of trusted root CAs. This can be checked by the client because the certificate hierarchy path (with the digital signatures of issuing CAs) is included in the certificate which comes from the LDAP server.

You see these three main criteria when you display a certificate with the Windows standard dialog:

Information on a certificate

Another criterion which could be important is the fact that the issuing CA could have revoke the certificate of the LDAP server. This is announced on certificate revocation lists which are published by the CA - the address of this list is included in the certificate. So if the LDAP client cannot reach the regarding revocation list, he cannot check if the certificate was maybe revoked by the CA. In most cases, this is regarded as a problem but it doesn't lead to a connection error - this depends on the secure channel settings of the operating system.

All these criteria can lead to failure in the beginning of an SSL session if not fulfilled. The three main criteria will cause trouble for sure if the client detects that something wrong with them:

Invalid SSL certificate



Ignoring SSL certificate errors


SSL encryption can implemented between the server and the client, although the certificate check failed! this means: The client cannot be sure about the identity of that server, but nevertheless the SSL session could be initiated:

Certificate check failed

Please note that this is not a recommended configuration. If you ignore the certificate errors, then you cannot be sure about the identity of the LDAP server. You just do not know if the server to which you transfer user and password data is really the one you think it is!

But sometimes it is better to accept this risk than to communicate without encryption. So these are the ways to ignore certificate errors in LDAP/SSL sessions:

  1. Just press the Ignore button if the error message appears when the connection starts.

    Invalid SSL certificate

  2. If you try to start an LDAP connection from a connection profile, LEX can change the setting in the profile so that the certificate errors are ignored every time. The error message is slightly different in such situations:

    Invalid SSL certificate

    You can Press the Always Ignore button here. This is the settings in the connection profile which is changed then:

    Profile setting to ignore cert errors

LEX informs you whenever you are running an SSL session which had certificate errors. Look at the symbol in the right bottom corner of the LEX main window:

Indication of an invalid SSL certificate in  the status bar

Be aware that although there was a problem with the certificate, the session is encrypted! To see what exactly the problem was, just double-click on the symbol.


Fixing SSL certificate errors regarding the name


It is better to fix an error than to ignore it. Some of the common problems with certificates are easy to fix.

If you get an LDAP certificate error which says that the servers name you use doesn't match the name in the certificate, then change the name setting in LEX accordingly. An example:

Name error in certificate check

In this case, the address 192.168.0.44 is used in the LEX connection settings. But the certificate common name is dc01.cerrotorre.de. So just use this name in LEX also:

Fixing an cert name error


Fixing SSL certificate errors regarding the cert trustworthiness


It is better to fix an error than to ignore it. Some of the common problems with certificates are easy to fix.

If you get an LDAP certificate error which says that there was problem in the trust chain or there was an unknown root certificate authority (CA) cert, you can add the root CA cert to your list of the trusted root CAs. Of course only if you know the regarding CA and know that you can trust it!

An example:

Root CA in certificate check

In this case, the certificate authority which issued the LDAP server certificate is not known (and therefore not trusted) by the client. By the way: You have to pay attention because it might be the case that only the error message text '[32] Untrusted root' without any further explanations appears.

To solve this problem, you have to add the root CA cert in your local list of trusted root CAs. Fortunately, this certificate is normally included in the server certificate which was just checked and complained about by LEX! So first of all, you have to use the Show Cert button to open the official Windows certificate display dialog, where you have to go to the Certification Path tab:

Importing the root CA: Step 1

You should see here what parent certificate in the certificate hierarchy ('path') is untrusted and causes the trouble. Select this certificate and use the button View Certificate here. Another certificate display dialog is shown with the root cert, you can now use the Install Certificate... button to insert this certificate.

Importing the root CA: Step 2

A wizard (which depends on the windows version you are currently running) helps you to store this certificate into the list of Trusted Root Certificate Authorities on your machine. You can check the result with the Microsoft Management Console (MMC) and the Certificate plug-in:

Importing the root CA: Step 3