LDAPviewer provides extensive TLS/SSL support features including the LDAPS protocol and STARTTLS service for server authentication using standard TLS/SSL (X.509) certificates. In addition, LDAPviewer supports mutual authentication (the client also provides a TLS/SSL (X.509) certificate). Finally, LDAPviewer allows the use of non-standard (such as self-signed) certificates and user-control and inspection of received certificates prior to accepting a connection. This may all appear rather confusing if the user's only requirement is to connect to a TLS/SSL secured LDAP server. The following section describes how to configure such a service. Subsequent sections describe progressively more complex connections which can be mercifully skipped if not required.
In this section we assume that the LDAP server is configured to support TLS/SSL and that any login/connection is mandated to use TLS/SSL, that is, you will not be able to connect to the LDAP service without using TLS/SSL.
LDAP supports two ways of providing a TLS/SSL service. (The LDAP server administrator may need to be contacted to determine which method is supported or the service description may provide these details.)
The first method involves using the LDAPSv3 protocol (LDAP over TLS/SSL), selected from the Protocol section of the Connection Profile. By convention, the LDAPSv3 service is provided on port 636 but server administrators can configure the LDAPS service on any port number. (When you select the LDAPSv3 protocol a warning message is displayed if a non-standard port number is being used. This prompt may be suppressed by using the Preference: LDAPS Prompt option.) When the LDAPSv3 protocol is selected a URL of the form ldaps://host.name:port is used to connect to the LDAP server. In this mode, all communication to the server using the defined port number uses TLS/SSL. When LDAPSv3 is selected the Access Type: parameter of the Connection Profile implicitly adds the TLS option to the selected value if not present. Thus, if user+password is selected the connection will implicitly use TLS+user+password.
Select Protocol: LDAPSv3 and then, in the Access Type: drop-down menu, select any type with or without TLS (anonymous, user+password, TLS+anonymous or TLS+user+password) and enter a User DN and Password if required by your selection. In this case, selection of LDAPSv3 ensures that the session negotiates TLS when initially opened and that authentication (if specified) always takes place on an encrypted connection - specifically, passwords are never sent in plain text. This is the simplest and most secure form of cnfiguration if your LDAP server supports the service.
Note: This configuration assumes that a standard TLS/SSL (X.509) certificate, for which the Java environment has root certificates, is used by the LDAP server. To review which root certificates are available to your standard Java environment use View All Certificates from the Certificates menu: To import additional root (CA) certificates (including self-signed certificates) into the standard Java Trusted Keystore: To configure and populate an alternative source of validation certificates (User's Trusted Keystore) (including self-signed certificates): To configure client certificates (used in mutual authentication): To invoke manual inspection and approval of the TLS authentication process and, finally, to allow any certificate to be automatically accepted (including self-signed certificates) without validation.
The second method involves using the StartTLS directive on a non LDAPSv3 connection. If the user selects LDAPv3 in the Protocol section of the Connection Profile a URL of the form ldap://host.name:port will be used to connect to the LDAP server. In this case the Access Type: determines whether StartTLS will subsequently be invoked or not. Thus, if the user selects user+password with the LDAPv3 protocol, StartTLS will not be invoked and the entire session including authentication (with password transmission) will use plain text. If, however, TLS+user+password (or any other option including the TLS keyword) is selected then StartTLS will be invoked and the entire session including authentication (with password transmission) will be encrypted.
Note: when StartTLS is invoked certificate validation is mandated (by RFC 7817 and others) to include validation that the hostname used to access the server (URL) appears in the subject (or subjectAltName (SAN)) attribute of the server's certificate. Specifically, if a server is accessed using a URL of, say, ldap://localhost:389 and the server's certificate has a value of, say, cn=ldap.example.com in its subject (or SAN) attribute then normal validation will immediately fail. In this case it is essential to use the full server URL which, in this example case, would be ldap://ldap.example.com:389. LDAPviewer provides a number of alternative solutions which are discussed in the advanced section.
Select Protocol: LDAPv3 and then, in the Access Type: field, select any type with TLS (TLS+anonymous or TLS+user+password) and enter a User DN and Password if required by your selection.
Note: This configuration assumes that a standard TLS/SSL (X.509) certificate, for which the Java environment has root certificates, is used by the LDAP server. To review which root certificates are available to your standard Java environment use View All Certificates from the Certificates menu: To import additional root (CA) certificates (including self-signed certificates) into the standard Java Trusted Keystore: To configure and populate an alternative source of validation certificates (User Keystore) (including self-signed certificates): To configure client certificates (used in mutual authentication): To invoke manual inspection and approval of the TLS authentication process and, finally, to allow any certificate to be automatically accepted (including self-signed certificates) without validation.
LDAPviewer provides four features to extend control over TLS certificate processing. The first two involve modifying or replacing the standard Java Trusted Keystore but use Java's native X.509 certificate validation process. (Note: Keystore is a widely used term to describe a, normally password protected, file which contains a mixture of root (CA) and intermediate certificates used to validate incoming X.509 certificates from a server.) The second two methods bypass Java's native X.509 certificate validation process entirely.
These methods would normally only be required if the LDAP server is using a non-standard, for example, self-signed, certificate. At all other times the normal Java Trusted Keystore should contain the necessary root and intermediate certificates to enable X.509 certificate validation. (To review which root and intermediate certificates are available in your standard Java environment use View All Certificates from the Certificates menu.)
Use of Advanced TLS/SSL features is configured on a Connection Profile level not an application level so features can be tailored to the requirements of a particular connection.
LDAPviewer permits X.509 certificates to be imported (added) into the standard Java Trusted Keystore using the View or Import Security File item on the Certificates menu. Certificates may be imported from .der, .pem, .cer, , .crt, .p12 or .pfx files. Once the certificate is imported it will be used by Java's normal validation function to verify incoming certificates from the LDAP server.
Note: This feature will permanently modify the standard Java Trusted Keystore. If the certificate use is temporary then one of the following methods may be more suitable. When importing certificates into the Java Trusted Keystore LDAPviewer must be run with administrator privileges.
Use View or Import Security File item on the Certificates menu to import the required certificate (you will need to run LDAPviewer with Admin privileges to do this). In the Connection Profile under TLS select the Check (default) radio button, save the Profile and connect to the server.
LDAPviewer allows the user to configure an alternative Keystore (User Trusted Keystore) that will be used by the normal Java certificate validation function to verify incoming certificates as an alternative to its normal Trsuted Keystore. This alternative (User's Trusted) Keystore is configured and populated using the Manage User's Trusted Keystore item on the Certificates menu.
Use the Manage User's Trusted Keystore item on the Certificates menu to create and populate the alternative Keystore. In the Connection Profile under TLS check the KS radio button, save the Profile and connect to the server.
Note: The alternative Keystore may be deleted at any time by user action. Any Connection Profiles that are using the KS feature will generate a user prompt as shown:
In addition to supporting use of java's standard certificate validation, LDAPviewer provides two features that allow user control over certificate acceptance and which entirely bypass Java's normal certificate validation procedures. Both involve an element of risk and should only be used with extreme caution and never for production environments. Both methods work with either LDAPS or StartTLS.
When using Manual Control the user is presented with the X.509 certificate received from the LDAP server and may accept or reject the certificate as shown:
The user may inspect the received certificate and all its attributes as described in Certificate Details. No connection activity takes place until the certificate is either accepted or rejected. If the certificate is accepted the connection continues normally and, following completion of the TLS handshake, any required LDAP authentication is invoked (any password is sent on an encrypted session and cannot be snooped). If the certificate is rejected the connection is immediately terminated (LDAP authentication is not invoked and no password exchange takes place).
Note: Manual Control allows the user to bypass the normal Java certificate authentication methods and accept, for example, non-standard and self-signed certificates or as a diagnostic to inspect suspicious or questionable certificates. However, it relies on the user having sufficient knowledge to identify acceptable certificates. It should not be used in a production environment.
In the Connection Profile under TLS check the User radio button, save the Profile and connect to the server.
LDAPviewer may be configured to bypass the normal Java TLS certificate validation and accept any LDAP server certificate automatically and without user intervention. This mode is extremely risky and should be used only in very controlled circumstances such as a closed, private network or during testing. It must never be used in a production environment.
In the Connection Profile under TLS check the Any radio button, save the Profile and connect to the server.
LDAPviewer may be configured to send a Client Certificate during the TLS handshake using either LDAPSv3 or StartTLS. When using this mode of operation the server must be configured to request a certificate and must be configured with the necessary root (CA), and if necessary, intermediate certificates, to enable the Client Certificate to be validated by the LDAP server.
The Client Certificate(s) and their associated Private Keys are stored in a Client Keystore which may be created and populated using the Manage Client Keystore item on the Certificates menu. Unlike the User's Trusted Keystore, which only contains public keys, the Client Keystore will contain highly sensitive private keys and should be secured with a carefully chosen password value.
Create, and populate with one or more certificates and their associated private keys, the Client Keystore. Select LDAPSv3 in the Protocol section of the Connection Profile (changing the port number if required by the server), and select any Access Type: containing the keyword Client. Enter credential information if required by the Access Type, save the profile and connect to the server.
Create, and populate with one or more certificates and their associated private keys, the Client Keystore. Select LDAPv3 in the Protocol section of the Connection Profile (changing the port number if required by the server), and Select any Access Type: containing the keywords TLS and Client (specifically either TLS+Client+Anonymous or TLS+Client+User+Password). Enter credential information if required by the Access Type, save the profile and connect to the server.
© LV Project 2016. Creative Commons Attribution 4.0 International License.