Reload Attribute Info
Compare this Object with another
Add New Attribute
Add Attribute Element to an Array
Remove Attribute
Show only Attributes that have Values
Show Friendly Object Names
Show Distinguished Name in Novell Notation
Show Hex Output for Hex Values
Show Multivalued Attributes
Set Attribute List Filter
Show Attribute Names and ValuesLDAP 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:
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.
To configure an LDAP session to use SSL, just activate the SSL checkbox in the LDAP Connection dialog:
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:
If the server does not support SSL, you get an 'LDAP server unavailable' error message.
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:
There are three main criteria for the client to check the validity of the certificate:
You see these three main criteria when you display a certificate with the Windows standard dialog:
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:
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:
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:
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:
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.
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:
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:
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:
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:
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.
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:
