The following text is based on the documentation from http://docs.sun.com/source/816-6698-10/ssl.html
This is something I never had an opportunity to do often, but whenever I did, I had to dig throughout heaps of notes and documents to find what I needed. Namely, if you want to set up Directory Server 5.2 for testing/piloting/playing purposes, SSL would definitely be something you would want to play with. However, not having certificate authority to generate certificates would certainly make it a lot harder for you to get the basic setup up and running.
Thing to be done first is to create the certificate database for DS by using certutil:
certutil -N -d ServerRoot/alias -P slapd-ServerID-
Now we need to make a certificate request:
certutil -R -s "cn=serverName,ou=division,o=company,l=city,st=state,c=country" -a -d ServerRoot/alias -P slapd-serverID- -o cert.req
This will save the certificate request into file cert.req. At this point you should send the file to your certificate authority to sign it and to produce the actual certificate. Apart from the certificate for the server, the CA has to provide you root certificate of it's own and/or certificate chain so you could trust it. Importing is as follows:
certutil -A -n "certificateName" -t "u,," -a -i certFile -d ServerRoot/alias -P slapd-serverID-
and for root CA:
certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile -d ServerRoot/alias -P slapd-serverID-
where trust is one of the following:
- T - This CA is trusted to issue client certificates. Use this code if your LDAP clients perform certificate-based client authentication by presenting certificates issued by this CA.
- C - This CA is trusted to issue server certificates. Use this code if your server will play a replication supplier or chaining multiplexor role over SSL with another server that has a certificate issued by this CA.
- CT - This CA is trusted to issue both client and server certificates. Use this code if both cases above apply to this CA.
In case you are playing with a test server and you do not have a CA, you can create a self-signed certificate and use it as CA:
certutil -S -x -s "cn=CA" -n ca -t "TC,,," -1 -2 -5 -d ServerRoot/alias -P slapd-serverID-
In case the certificate request file is not in ASCII format (as it should be if the above command was used to generate it) then from the following command -a should be removed:
certutil -C -a -i cert.req -o node1.crt -c ca -d ServerRoot/alias -P slapd-serverID-
Now you can add the generated certificate:
certutil -A -i node1.crt -n server -t "P,P,P" -d ServerRoot/alias -P slapd-serverID-
At this point, SSL database should be ready to be used. Next thing to follow is to reconfigure DS to use SSL. Edit DS configuration to enable SSL either by manually chaning dse.ldif or by LDIF. If you chose to edit dse.ldif file do not forget to shut down DS first! Either way, the LDIF file should look like this:
nsSSLToken: internal (software)
In order for DS to start automatically you need to edit ServerRoot/alias/slapd-serverID-pin.txt and put the following content:
Internal (Software) Token:password
Now you can start your DS service. From now on DS should be listening also for SSL connections. It is important to note that the approach with self-signed certificates would work only with a single DS instance. For multiple instance s you would have to export CA certificate and import it to other DS instances. This is easily achievable with pk12util. For example:
pk12util -d ServerRoot/ -P slapd-nis- -o ca.crt -n ca