 Using Certutil to Self-Sign Certificates -- Part 1
Justin Buhler
An SSL-enabled Web site is considered the norm these days for the deployment of any production Web site, but what about the staging and development environments? You know, where the production site began life? Logic would indicate that these environments closely resemble production, but my own experience has been that this is not always the case. There is nothing worse then being up at 1:00 a.m. at a site launch to discover that what worked in the testing/staging environment does not work in production. And, I have seen such a configuration gap between development and production in SSL-enabled Web sites.
I think part of the reason for this gap is the lack of knowledge of the product, beyond its core functionality, and the utilities that are delivered with that product. One such utility is "certutil", which is part of the NSS (Network Security Services) Library Implementation and is included with both the Sun Java Web and Directory Servers.
In this series of two articles, I will provide the how-to information for configuring end-to-end SSL configurations on both the Sun Java Web Server and Sun Java Directory Server. I will be using the certutil binary delivered with each Sun Java Server product. All the examples presented here use the Slackware 11 Linux operating system.
WARNING: The CA certificate you produce with the NSS tools is a self-signed certificate that works correctly for testing purposes, but it should not be used in a real-world deployment. Similarly, the client SSL and server SSL certificates created with the NSS tools are for testing purposes only. To deploy certificates used in a real public-key infrastructure (PKI), you should use either a third-party CA or a certificate server (such as Netscape Certificate Management System) to set up your own CA and issue certificates. The Certificate Database Tool does not provide the facilities for a full-blown PKI deployment, and the certificates it creates should not be considered trustworthy for that purpose:
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/ \
gtstd.html#1011987
Introduction to Certutil
Certutil is a security tool delivered as part of the open source NSS (Network Security Services) Library Implementation, which is available at:
http://www.mozilla.org
The tool allows for the creation and management of certificates and certificate data stores, which are the two core pieces and most important components when enabling a Web server to provide HTTPS services. It is important to have a good understanding of SSL and the NSS architecture before continuing. An overview of NSS and other topics specific to the SSL as a protocol can be found at:
http://www.mozilla.org/projects/security/pki/nss/overview.html
Historically, the certutil binary has come with very little documentation, which was frustrating to say the least. But that has changed during the past couple years. The Mozilla project site for the NSS libraries and the mozilla.dev.tech.crypto News group for that project are excellent sources of information. The certutil man pages can be found here:
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
The first step, however, is to determine which version of the NSS and NSPR libraries the server products are compiled with. This version information can be used to determine which NSS functionality is available. The quickest way to determine NSS version information is to read the release notes for the server products at:
http://docs.sun.com
The release notes contain a section that describes NSS and NSPR version installed for either the 32-bit or 64-bit installations.
Armed with the version information, you can identify the options available for the certutil that was included with your server software by going to the following URL:
http://www.mozilla.org/projects/security/pki/nss/release_notes.html
If you would like to try the latest versions of the NSS utilities, you can download them in binary or source form. The tarball of the NSS source code can be downloaded and compiled from:
http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases
http://ftp.mozilla.org/pub/mozilla.org/nspr/releases
All examples discussed in this series can be done with the latest versions of the NSS utilities.
SSL-Enable Sun Java Web Server and Administration Server
Let's look at the first example of using certutil to enable SSL in the Sun Java Web Server Administration Console. A good best practice to implement in your organization is to perform all administration over a secured connection as there is the potential for the username and password being compromised over network connections. The following steps can be used to enable SSL for any other Web server configured within the Sun Java Web Server.
Before we go further into using the certutil, there are a couple of items that you should validate.
- Ensure that the Web server administration server is configured to listen on a single interface (not required for SSL configuration).
- Ensure the IP address of the administration server has a configured FQDN and is resolvable by clients, which will access the administration server.
Note that the following steps assume that you are already familiar with the installation of the Sun Java Web server; therefore, it will not be covered. The following also assumes that the Web server has been installed under the directory /jes/ws61.
WARNING: The following is performed using root privileges. The certutil binary is located in /bin/https/admin/bin under the root installation directory /jes/ws61. If you try to execute the command, you will receive the following error message. This is because the certutil cannot locate the NSS libraries required.
root@fry:/jes/ws61/bin/https/admin/bin# ./certutil
./certutil: error while loading shared libraries: libssl3.so: \
cannot open shared object file: No such file or directory
You must configure the LD_LIBRARY_PATH environment with the path to the NSS libraries delivered with the Web server.
root@fry:/jes/ws61/bin/https/admin/bin# export \
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/jes/ws61/bin/https/lib/bin/ \
https/admin/bin
Additional set the PATH temporarily
root@fry:/jes/ws61/bin/https/admin/bin$ \
export PATH=$PATH:/jes/ws61/bin/https/admin/bin
In the Linux environment, run the following:
root@fry:/jes/ws61/alias# echo "/jes/ws61/bin/https/lib" \
>>/etc/ld.so.conf
root@fry:/jes/ws61/alias# ldconfig
Now when you execute the certutil command, you should see the following:
root@fry:/jes/ws61/bin/https/admin/bin$ ./certutil
certutil: you must enter a command!
Type certutil -H for more detailed descriptions
..... output removed .....
Here are the steps to follow:
1. Create Administration Server Certificate Database
Run the following commands under the alias directory located in /jes/ws61 to create a new certificate database for the administration server. Execute the certutil command with the -H flag for a description of the command switches.
The certificate database is where the administration server stores the servers SSL certificate. To generate the certificate store run the following command with the options below:
root@fry:/# cd /jes/ws61/alias
root@fry:/jes/ws61/alias# certutil -N -d . -P https-admserv-`hostname`-
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/ws61/alias# ls -l
total 96
-rw------- 1 root root 65536 2006-12-14 15:38 https-admserv-fry-cert8.db
-rw------- 1 root root 16384 2006-12-14 15:38 https-admserv-fry-key3.db
-rw------- 1 root root 16384 2006-12-14 15:37 secmod.db
root@fry:/jes/ws61/alias#
**Only applicable if you have created a certificate database with a password.
Note: You must include the "-" at the end of the hostname, otherwise the command will create the wrong keys database.
If you decide to use a blank password, then you will not be required to enter a password file. Not using a password can be a convenience in a development environment but, in production, protecting your private keys is absolutely necessary. Even though the keystore needs only to be readable by the Web server's process, storing the passwords in clear text for accessing the keystore is generally considered a weak security measure.
The following blog provides a nifty little hack to work around this weak security implementation:
http://blogs.sun.com/jyrivirkki/entry/secure_password_storage
2. Create the Server Certificate
The server certificate is used to authenticate/valid the system to the Web browser client. It also is used to facilitate the encryption algorithm used between the Web browser and administration server, which keeps the traffic confidential. To generate the server certificate, run the following command with the options below:
root@fry:/jes/ws61/alias# certutil -S -n adminServerSSL -s \
"cn=fry.demossl.com" -t CTu,, -g 1024 -x -v 24 -d . -P \
https-admserv-`hostname`-
Enter Password or Pin for "NSS Certificate DB":
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 AUTOREPEAT 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/ws61/alias#
Note: cn= must be the DNS NAME of the server or local hostname of the cluster including the domain (e.g., lab-s1uxmgt-001.games2004.gr). Also, you must include the "-" at the end of the hostname, otherwise the command will create the wrong keys database.
3. Verify the Creation of the Server Certificate
root@fry:/jes/ws61/alias# certutil -L -d . -P https-admserv-fry- \
-n adminServerSSL
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
00:84:93:09:23
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: "CN=fry.demossl.com"
... cut output ...
4. Configure Administration Server Listen Sockets
The administration server listens on port 8888 by default on an insecure socket. To enable the administration server to listen over an SSL connection, edit the .../https-admserv/config/server.xml file and change the line that reads:
<LS id="ls1" ip="any" port="8888" servername="fry.demossl.com" \
defaultvs="vs-admin" security="off" ip="any" blocking="false" \
acceptorthreads="1">
to:
<LS id="ls1" port="8888" servername="fry.demossl.com" \
defaultvs="vs-admin" security="on" ip="any" blocking="false" \
acceptorthreads="1">
All we're changing here is the value of the "security" parameter from "off" to "on".
You will also need to add a new line immediately after the line above in order to set the appropriate SSL parameters:
<LS id="ls1" port="8888" servername="fry.demossl.com" \
defaultvs="vs-admin" security="on" ip="any" blocking="false" \
acceptorthreads="1">
<SSLPARAMS servercertnickname="adminServerSSL" ssl2="off" \
ssl2ciphers="-rc4,-rc4export,-rc2,-rc2export,-desede3,-des" \
ssl3="on" tls="on" \
ssl3tlsciphers="+rsa_rc4_128_sha,+rsa_rc4_128_md5, \
-rsa_rc4_56_sha,-rsa_rc4_40_md5,+rsa_3des_sha,+rsa_des_sha, \
-rsa_des_56_sha,-rsa_rc2_40_md5,-rsa_null_md5,-fortezza, \
-fortezza_rc4_128_sha,-fortezza_null,+fips_3des_sha, \
-fips_des_sha" tlsrollback="on" clientauth="off"/>
</LS>
Note: The value of the servercertnickname parameter ("adminServerSSL" in our example) must match the value of the -n option to the certutil command you used when creating the server certificate in Step 2.
I suggest configuring the listen socket using the administration interface, because it will ensure proper configuration. This is fairly straightforward; once you connect to the administration server and login, do the following:
Select the Preferences Tab -> Edit Listen Sockets -> ls1 -> Security: Enable -> Server Certificate Name: adminServerSSL -> OK
Then, shut down the administration server:
root@fry:/jes/ws61/https-admserv# ./stop
server has been shutdown
5. Configure SSL Password (Optional)
Once SSL is enabled, the administration server must be able to access its own certificate; therefore, it must have the password used to create the database, which stores the certificate. The following allows the administration server to automatically start and access its own cert without prompting you for the password:
root@fry:/# cd /jes/ws61/https-admserv/config
root@fry:/jes/ws61/https-admserv/config# cat >password.conf <<EOF
> internal:Iamthepassword
> EOF
root@fry:/jes/ws61/https-admserv/config# chmod 600 password.conf
root@fry:/jes/ws61/https-admserv/config# chown root:root password.conf
root@fry:/jes/ws61/https-admserv/config# ls -l password.conf
-rw------- 1 root root 24 2006-12-14 16:41 password.conf
root@fry:/jes/ws61/https-admserv/config# cat password.conf
internal:Iamthepassword
Note: Make sure the password file has correct permissions. Keep the password secret. As an alternative see:
http://blogs.sun.com/jyrivirkki/date/20060603
6. Test SSL Configuration
The administration server is now ready to be started and validated for the correct configuration. The following shows how to verify the correct configuration of the SSL certificate:
root@fry:/# cd /
root@fry:/# cd /jes/ws61/https-admserv/
root@fry:/jes/ws61/https-admserv# ./start -configtest
Sun ONE Web Server 6.1SP6 B05/07/2006 14:57
[14/Dec/2006:16:50:48] info ( 1262): CORE1116: Sun ONE Web Server \
6.1SP6 B05/07/2006 14:57
[14/Dec/2006:16:50:48] info ( 1262): CORE3016: daemon is running as \
super-user
success: configuration was parsed successfully/opt/sunone/iws6/ \
https-admserv/start
root@fry:/jes/ws61/https-admserv# ./start
Sun ONE Web Server 6.1SP6 B05/07/2006 14:57
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.4.2_04] \
from [Sun Microsystems Inc.]
info: WEB0100: Loading web module in virtual server [vs-admin] at \
[/admin-app]
info: HTTP3072: [LS ls1] https://fry.demossl.com:8888 ready to \
accept requests
startup: server started successfully
Next, connect via browser to:
https://ipaddress-of-server:4242
You will get a warning message if you are not connecting with the DNS name as well as the fact that the CA certificate is not trusted by your browser.
The SSLtap utility is delivered as part of current NSS library distribution, but not with the Sun Web server. This tool can be used to verify the SSL connectivity between any client and the SSL service by acting as a proxy for the communication between the client and the SSL-enabled service.
The tool can be used as follows on the SSL Service host:
root@fry:/data/nss/bin# ./ssltap -fsl -p 4441 192.168.184.10:8888
<HTML><HEAD><TITLE>SSLTAP output</TITLE></HEAD>
<BODY><PRE>
Looking up "192.168.184.10"...
Proxy socket ready and listening
<p><HR><H2>Connection #1 [Thu Dec 14 17:13:13 2006]
</H2>Connected to 192.168.184.10:8888
--> [
<font color=blue>(70 bytes of 65)
SSLRecord { [Thu Dec 14 17:13:13 2006]
type = 22 (handshake)
version = { 3,1 }
length = 65 (0x41)
handshake {
type = 1 (client_hello)
... cut output ...
This is a great way to debug the handshake process between the client and host, however, that data is still encrypted.
WARNING: It is recommended for reasons of security to allow the administration Web server to be running for configuration purposes only. When the configurations are completed, turn the administration Web server off.
Remember that you can repeat Steps 1-6 for additional Web servers. The only exception is that you'll need to change the name of the certificate database from:
https-admserv-'hostname'-
to
https-'hostname'-
Conclusion
I hope I've shown that with a little effort, you can ensure that your development and staging regions are consistent with your production, without the burden of going through the CA enrollment process for systems that are most likely isolated from external clients.
In my next article, I will cover how to SSL-enable the Sun Java Directory Server as well as SSL-enable the traffic from the Directory Console to the Directory and Administration Servers. The same certutil procedure will be used to generate the certificates, but the sequence will be important. Until then, happy trails.
Resources
Jyri Virkki's Blog -- http://blogs.sun.com/jyrivirkki
Network Security Services -- http://www.mozilla.org/projects/security/pki/nss/
Sun Java System Web Server 6.1 SP6 -- http://docs.sun.com/app/docs/coll/1308.2
Weber, Stefo. 2002. Securing LDAP Through TLS/SSL -- A Cookbook. Sun BluePrints OnLine. -- http://www.sun.com/blueprints/0602/816-5203-10.pdf
Justin Buhler currently resides in Bozeman, Montana working for a financial services company. You can contact him at: Justin.buhler@gmail.com.
|