Secure Sockets Layer
To provide secure communications over the network, the Netscape
Directory Server provides the LDAPS communications protocol. LDAPS is the
standard LDAP protocol, but it runs on top of Secure Sockets Layer (SSL).
Background
The Secure Sockets Layer allows secure transmissions over both the
Internet and intranets. An SSL connection can occur only between an
SSL-enabled client and an SSL-enabled server.
Essentially, SSL provides the following:
-
Server authentication to ensure that communications are occurring between
the correct servers and clients. Currently the Directory Server supports
only server authentication; client authentication is not supported at this
time.
-
Encryption to ensure that only the communicating entities know what data
is being transmitted.
Managing SSL
To provide secure communications over the network, the Netscape
Directory Server provides the LDAPS communications protocol. LDAPS is the
standard LDAP
protocol, but it runs on top of Secure Sockets Layer (SSL).
To use LDAPS, you have to first setup a certificate database for your
directory, and then you have to turn on SSL. You create certificate databases
using the Netscape Administration Server.
The following sections assume that you understand SSL and that you have
already created a certificate database. They describe how to turn SSL on
and off in your Directory Server.
Activating SSL
After your certificate database is created, you can activate
SSL for your server.
1. In the Server Manager, choose System Settings | Encryption
On/Off.
2. Click the Yes button.
3. Type the port number you want your server to use. 636 is used by
default. Make sure you select a unique port number.
4. Click OK. Save and apply your changes.
5. Stop and then restart your server.
Setting Security Preferences
You can choose the type of cipher to use for SSL. To do so,
choose System Settings | Encryption Preferences in the Server Manager.
After you make your changes, you must click OK and confirm your changes.
A cipher is the algorithm used in encryption. Some ciphers are more
secure or stronger than others. Generally speaking, the more bits a cipher
uses during encryption, the harder it is to decrypt the data.
When a client initiates an SSL connection with a server, it lets the
server know what ciphers it prefers to use to encrypt information. In any
two-way encryption process, both parties must use the same ciphers. Since
there are a number of ciphers available, your server needs to be able to
use the most popular ones.
You can choose ciphers from the SSL 3 protocol. To specify which ciphers
your server can use, check them in the list. Unless you have a compelling
reason to not use a specific cipher, you should check them all.
Another reason you might not want to enable all ciphers is to prevent
SSL connections with less than optimal encryption. That is, United States
law prohibits the export of products with 128-bit encryption, so overseas
clients might only be using 40-bit encryption, which is not as difficult
to crack as 128-bit. Unchecking all 40-bit ciphers effectively restricts
access to clients available only in the United States.
Domestic versions of the Directory Server provide the following SSL
3.0 ciphers:
RC4 cipher with 128-bit encryption and MD5 message authentication.
RC4 cipher with 40-bit encryption and MD5 message authentication.
RC2 cipher with 40-bit encryption and MD5 message authentication.
DES with 56-bit encryption and SHA message authentication.
Triple DES with 168-bit encryption and SHA message authentication.
No encryption, only MD5 message authentication.
Export versions of the Directory Server provide the following SSL 3.0 ciphers:
RC4 cipher with 40-bit encryption and MD5 message authentication.
RC2 cipher with 40-bit encryption and MD5 message authentication.
No encryption, only MD5 message authentication.
Using Certificate-Based Authentication
Your LDAP
clients can bind to the Directory Server using certificates
rather than normal Bind DN/Password authentication. This kind of authentication
provides two things for you:
Under some circumstances it is more convenient to provide a certificate
for authentication purposes than to continually have to provide a Bind
DN/Password credentials. This is true for situations where you are using
applications that prompt you once for your certificate database password,
and then use that certificate for all subsequent bind or authentication
operations.
The use of certificate based authentication is more secure than non-certificate
bind operations. This is because certificate-based authentication uses
public-key cryptography. As a result, bind credentials can not be intercepted
across the network.
Out of the box, the Directory Server allows you to use certificate-based
authentication using the command line client tools and for replication
communications.
To setup certificate-based authentication, you must:
1. Create a certificate database for both the client and the server.
In the case of supplier-server to
consumer-server replication, you need a certificate
database for both servers.
2. Obtain a certificate for both client and server.
3. Map the certificate's distinguished name to a DN known by the
Directory Server.
This allows you to set access control for the client when
it binds using this certificate.
|