 Using Certutil to Self-Sign Certificates -- Part 2
Justin Buhler
In the previous issue of Sys Admin (May, 2007), I laid the foundation for using the certutil application from www.mozilla.com to roll your own self-signed certificates for Sun Java Web servers within your development environment. In this follow-up article, I will show how to use the same steps to SSL-enable the Sun Java Directory Server as well as the Directory Administration Console. As stated in the previous article, all examples are performed as the root user on a Slackware 11 image. It is also assumed that you have working knowledge of the Sun Java Directory Server.
The Sun Java Directory Server Administration Architecture consists of three components: Java Administration Console Client application, Java Administration Web Server, and the Java Administration Directory Server itself (NetscapeRoot). All of these can be installed separately on different servers or combined onto a single server. The goal is to implement SSL communication between each component to ensure that all administration functions occur over a secure connection.
Figure 1 shows the relationship of three components and provides the sequence we will follow to enable SSL communication among the administration components. If you do not follow the proper sequence, you can lock yourself out of the administration console.
Prepare the Environment
Before you enable SSL communication between the administration components you must ensure that the FQDN of each server has been configured and can be resolved by all hosts. For an overview of the SSL handshake process, see the references section.
To access the certutil provided with the Sun Java Directory Server, you must set the LD_LIBRARY_PATH and PATH environment variables:
root@fry:/# cd /jes/ds52
root@fry:/jes/ds52# export PATH=$PATH:/jes/ds52/shared/bin
root@fry:/jes/ds52# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/jes/ds52/lib
Create Directory Server Certificate Database and Self-Signed Certificate
The certificate database is where the administration server stores the server's SSL certificate. We need to create a certificate for the directory server process, slapd, which provides access to this database. To generate the certificate, run the following commands with the options as shown below. Note that you must include the "-" at the end of the hostname; otherwise the command will create the wrong keys database. Also, if you enter a null password, then you will not be required to manually enter one at startup, but the private key for the certificate will not be encrypted. Therefore, the private key must be protected by other means, such as directory permissions and restricting access to the server itself.
root@fry:/# cd /jes/ds52/alias
root@fry:/jes/ds52/alias# certutil -N -d . -P slapd-<instance name>-
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long, and should
contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
root@fry:/jes/ds52/alias# certutil -d . -P slapd-<instance name>- \
-S -n ldap-server-cert -s "cn=<FQDN of Server> " \
-x -t CTu,, -g 1024 -x -v 24
A random seed must be generated that will be used in the
creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.
To begin, type keys on the keyboard until this progress meter
is full. DO NOT USE THE AUTO-REPEAT FUNCTION ON YOUR KEYBOARD!
Continue typing until the progress meter is full:
|************************************************************|
Finished. Press enter to continue:
Generating key. This may take a few moments...
root@fry:/jes/ds52/alias#
Create Administration Server Certificate Database and Self-Signed Certificate
Now we must use similar commands to create a certificate for the administration server. Again note the trailing "-" at the end of the hostnames. The previous warning about using a null password also applies.
root@fry:/# cd /jes/ds52/alias
root@fry:/jes/ds52/alias# certutil -N -d . -P \
admin-serv-<instance name>-
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long and should
contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
root@fry:/jes/ds52/alias#
root@fry:/jes/ds52/alias# certutil -d . -P admin-serv-fry- -S \
-n admin-server-cert -s "cn=fry.buhlerfarm.com" -x -t CTu,, \
-g 1024 -x -v 24
...Output cut ...
root@fry:/jes/ds52/alias#
Export the Directory and Administration Servers Certificates into ASCII File
One of the most important steps in SSL authentication is the validation of the server's certificate. This validation occurs when the client authenticates the server's certificate against a trusted certificate authority (CA). This validation is possible because the client has a certificate from the CA, which is authorized to validate certificates generated by the CA. In this example, we must import the Directory Certificate into the Administration Server certificate Database as a Certificate Authority Certificate because the certificate was created with CA trust enabled (-t CTu). We will also import the Administration Server's certificate into the directory's certificate store database.
To import the cert, we must first export the certificate from each of the Certificate databases. To do this run the following command, which will export the key into ASCII format.
root@fry:/jes/ds52/alias# certutil -L -d . -P slapd-<instance>- \
-n ldap-server-cert -a > ldap.ascii
root@fry:/jes/ds52/alias# certutil -L -d . -P admin-serv-<instance> \
- -n admin-server-cert -a > admin.ascii
root@fry:/jes/ds52/alias# cat *-server-cert
-----BEGIN CERTIFICATE-----
MIIBsjCCARugAwIBAgIFAIV4dY8wDQYJKoZIhvcNAQEEBQAwHTEbMBkGA1UEAxMS
ZnJ5LmJ1aGxlcmZhcm0uY29tMB4XDTA3MDMxNjA0Mjg0OVoXDTA5MDMxNjA0Mjg0
OVowHTEbMBkGA1UEAxMSZnJ5LmJ1aGxlcmZhcm0uY29tMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCsQCPdrtUgaw2mjGjzQXJLLbjTUWvmAkLiViTzYY82miGi
NyWecTB1Cc6OZRCfRutQYYdB3iYBCZpT5kjQrB8e602H2rXuRdoc6vdKVUuKmsZ7
3c6hJRADZ0p2ni69gnPlLS3xvnt8sMTJY94FNDkZb1pjhydLrcT3t9be4TtjCwID
AQABMA0GCSqGSIb3DQEBBAUAA4GBAB3kPK4mstqVIs676oJlYrrN55tishgAZ3Mf
ygPks8V7EG0YkKtjU7Ywm1mnDd5fonSihyw0komaA4MvlC9sHTmnsscqlnDGF9pq
TxDVfj/ueDqNeVMHXX9hRFACvMF/RzIK7aXL82waDxAzUwiLZgsZ//D9X2c0mDda
vOVwar/V
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBsjCCARugAwIBAgIFAIV4dLswDQYJKoZIhvcNAQEEBQAwHTEbMBkGA1UEAxMS
ZnJ5LmJ1aGxlcmZhcm0uY29tMB4XDTA3MDMxNjA0MjcwMFoXDTA5MDMxNjA0Mjcw
MFowHTEbMBkGA1UEAxMSZnJ5LmJ1aGxlcmZhcm0uY29tMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCndUh80/JwdM4dzqf1WSRkaMaHUj7NrcuiOuye836gXeC8
MC9AK89URD+lNhyzWtCt9jkhqStdFXWv6FNNJbtiC8SpAPl30BYS0KLvQ5yJ9I79
GvJ76jPtWlusxVmOKHS1oiME+OdSYKNLNg4aNWUSU+i9k+xXEFi5QUIFy31yfwID
AQABMA0GCSqGSIb3DQEBBAUAA4GBAAz8qgvu5GfbdxIBtpUVAiZAGwRiDjyLMnRk
LXbJD0UcT9w6xnBuBzmKJvFcJY3GxYlPilYy+/MbiaQSsqaSo3gOfh8lLbLItcsU
s40XmFd12Cbol2yrL0+8Z+HFaWdjcwjaHJRkIH5IZfSRy61mcT7GADRYdMVvUTyw
Y5/rSar8
-----END CERTIFICATE-----
root@fry:/jes/ds52/alias#
Import the Directory Server Certificate into the Administration Server Certificate Store
root@fry:/jes/ds52/alias# certutil -A -d . -P \
admin-serv-<instance>- -n ldap-server-cert -t CTu,, -a \
-i ldap.ascii
root@jbuhler-vm:/usr/local/jes/ds52/alias# certutil -L -d . \
-P slapd-<instance>-
ldap-server-cert CT,,
ldap-server-cert CTu,u,u
Import the Administration Server Certificate into the Directory Server Certificate Store
root@fry:/jes/ds52/alias# certutil -A -d . -P slapd-<instance>- \
-n admin-server-cert -a -i admin.ascii
root@fry:/jes/ds52/alias# certutil -A -d . -P slapd-<instance>- \
-n admin-server-cert -a -t CTu,, -i admin.ascii
root@fry:/usr/local/jes/ds52/alias# certutil -L -d . -P \
admin-serv-<instance>
admin-server-cert CTu,u,u
admin-server-cert CT,,
SSL-Enable the Administration Components
Now that we have created our certificate stores, self-signed certs, and imported the certificates, we can finally make our server SSL enabled. At this point, it does not matter in what order you SSL-enable a service; however, it does matter whether you enable SSL communication between components, which we will configure later.
We will use the administration console, which was installed separately on our desktop, to perform the following operations. I will SSL-enable the administration server first and then the directory server. I will also highlight some icons on each console, which will enable you to know whether you are accessing a secure site.
Step 1: Log On to the Administration Server
You will notice that we connect not using https://, which means we are connecting to the Administration Server on an unsecured connection (see Figure 2). The lower left-hand corner on the console also indicates an unsecured pad lock indicating that the connection is not SSL enabled.
Step 2: Launch the Administration Server GUI
Navigate to the Administration Server icon and double-click it. Next, select the Configure Admin Server option on the screen (Figure 3).
Step 3: Enable SSL for the Administration Server
Select the encryption tab and select the options [Enable SSL for this server] and [Use this cipher family: RSA], then select the Certificate from the drop-down list. Once complete, click the OK option and a message will appear telling you to restart the Administration server. Click OK, then log out of the Administration console completely and restart your Administration server from the command line (Figure 4).
Step 4: Log On to the Administration Server Using the SSL Connection
You will now connect using https:// prefix, which means you are connecting to the Administration Server on a secured connection. You should now be prompted regarding the validity of the certificate, because you have not installed the CA into the client certificate store. Select Accept and continue to the Administration Server console. In the lower left-hand corner, you should now see a secure padlock indicating that the connection to the Administration Server is secure (Figure 5).
Step 5: Log On to the Directory Server to Enable SSL Communication
From the main administration screen, open the Directory Server Console by double-clicking the icon. Once inside the Directory Administration Console, navigate to the Configuration Tab and highlight the Directory Server FQDN in the left pane, then select the encryption tab in the right pane (Figure 6).
Step 6: Enable SSL for the Directory Server
Within the Encryption Tab, you will need to select the same option as in the Administration Server and then select Save (Figure 7). Do not modify any of the Client Authentication options. After you click OK, you will see the messages shown in Figure 8; just select OK for each of them. Then navigate to the Tasks Tab and choose to restart the Directory Server.
Step 7: Restart the Directory Server
When you restart the Directory Server from the Administration Console, you will receive the messages shown in Figure 9. Select YES to continue with the Restart. Notice in the dialogue box the server restarts and that both 389 and 636 are now LISTENING for LDAP requests.
SSL-Enable Communication Between Administration Components
Enabling communication between the Administration Server and the Directory Server is very straightforward. I will be quick in the steps required, because the heavy lifting is now over. We want to ensure that all communication between the Administration Server and the Directory Server is secured. To do this, we need to return to the Administration Server Configuration Screen (Figure 10).
Step 1: Enable SSL Communication to the Configuration Directory Server
To enable this secured communication for retrieving Administration Console configuration, you need to select the Configuration DS and select the [Secure Connection] option, which will also change the LDAP Port to 636. Once you click save, you will receive the following message indicating that the certificate is unknown. Click Accept (Figure 11).
Step 2: Enable SSL Communication to the User Directory Server
To enable this secured communication for retrieving User Information from the Directory, you will need to select the Administration Domain from the parent console as shown in Figure 12. Once the domain is highlighted, select edit and modify the line [User directory host and port], then change the port from [:389] to [:636]. Finally, select the [Secure Connection] check box. Click OK and log out of the console. The process is complete!
Summary
The value gained in implementing and testing security features like SSL early in any environment will ensure that you avoid potential interoperability issues later on. I hope this article has shown that with very little overhead along with utilities delivered with your products, you can avoid any interoperability issues in your environment as well.
References
Sidharth's Zone --http://blogs.sun.com/sid/entry/ssl_enable_directory_server_5
SSL Overview -- http://www.ourshop.com/resources/ssl.html
Sun Java System Administration Server 5.2 Administration Guide -- http://docs.sun.com/source/817-7612/
Justin Buhler currently resides in Bozeman, Montana working for a financial services company. You can contact him at: Justin.buhler@gmail.com.
|