tapman.net

Setting up LDAPS is a relatively complex process involving certificate installation and PKI configuration. LDAPS simply uses SSL encryption to protect the traffic between the two LDAP servers. In order to setup this encryption both servers need to be configured to setup the SSL session, which happens before the LDAP session is initiated.

LDAPS uses port 636 (TCP), in general, but can actually be run across any TCP port.

The LDAPS configuration needs to be considered in two directions. One server needs to be the host, or primary LDAP server. The other server will be the client, or secondary LDAP agent. Because of these two roles in the LDAPS relationship, it’s possible, and perhaps likely, that you will need to configure an LDAP server to fulfill both roles. One “side” of the server will provide information to clients or other servers, and the other “side” will query remote servers for information as if it were a client.

Setting up the host role is the most complex because it involves configuring a private/public key pair for use by the server. The following process refers to the process for a Windows 2003 server, however, the fundamentals are the same for either a Unix or Windows server. Initially, the server needs to be configured with a private key and SSL-enabled certificate. This handshake process takes place automatically between any SSL-capable client and server, and can be performed regardless of platform (e.g. a Linux server and Microsoft client).

Setting up a private key and certificate is a multi-step process. First, the server requiring the certificate needs to either generate a certificate request, or have a certificate request generated for it by a certificate service. You can use a program like OpenSSL or the Windows certutil function to generate a certificate request file or you can use a GUI-type feature like Microsoft web enrollment request form, which can be installed on a Microsoft Certificate Authority server. Either option is perfectly fine, however, the OpenSSL route is a little more esoteric, being command line driven, while the web route is easier to grasp on the surface but harder to adjust for unique circumstances…and requires Microsoft’s server products, which are expensive.

Using an OpenSSL model, generate the certificate request using this command:
openssl req -new -key private_key_file.pem -out cert_request_file.csr

…to be continued…