Ability to locate the SSL controls for the Server.
See Managing SSL in the Admin Guide.
Unlike other Netscape servers, the Directory Server is capable of simultaneous SSL and non-SSL communications. This means that you don't have to choose between SSL or non-SSL communications for your Directory Server; you can use both at the same time.
| # 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.

Copyright © 2000
Sun-Netscape Alliance