The importance of secure Web transactions is increasing, not only for online commerce but the maintenance of private corporate intranets as well. However, most users rely on their browsers and Web servers to take care of Web transaction security. Unfortunately, that’s not good enough for you developers who implement clients and servers yourselves.

Comprehensive security protocols and implementations have been added to Java in recent years, but they haven’t gained widespread use?most data still travels around networks unencrypted. Programmers may have valid reasons for not encrypting their data, but the main reason probably is too embarrassing for them to admit: encryption is hard. Even though many available systems and libraries are supposed to be relatively easy to use, the terminology is confusing and the systems are very general. Sometimes it seems only an expert could really find this stuff useful.

This article describes how to create a certification authority for Java-based systems. A certification authority is an entity that can provide authenticating certificates, enabling an organization to create a system of trust without pre-built software or commercial services. A custom certification authority is ideal for a corporate intranet, especially one built with custom clients and/or servers. You’ll learn how to create a certification authority and then use it to certify certificates for a secure Web server. You’ll also see how to install trusted certificates into a user’s browser, making integration with your secure Web server seamless.

Custom certificates created from scratch are an attractive alternative to certificates from a provider such as VeriSign or Thawte. Creating your own authorization infrastructure is not only more cost effective than purchasing third-party certificates in many cases, but you also might put more trust in security that you set up and control yourself. You could even consider selling your certification authority services.

You can install certificates in any Web server that supports the HTTPS protocol. If you don’t have access to a server you can configure, you can use a simple test server written in Java (click here for instructions). This test server will be easier to work with because the certificates you’ll be generating are in the right format for Java software to read. The same might not be true for another secure Web server.As commonly done in security literature, I describe different scenarios using a set of human characters. These characters are the players in each of the security interactions I discuss. Here is the cast of characters for this article:

• Alice. Alice is an innocent participant in communication. She generally is the sender, and she runs a secure Web server on a site called alice.com.
• Bob. Bob is another innocent participant who generally is the receiver.
• Celie. Celie is a certification authority who will be signing some certificates.
• Mallet. Mallet wants to impersonate Alice and send bogus Web pages to Bob. He has set up a fake version of alice.com with phony data. He stuck it on the Internet, hoping that people looking for alice.com instead would visit his machine, mallet.com.

In a typical scenario, Alice sends a piece of data to Bob; both entities want to hide their communication from Eve (the eavesdropper), and they definitely don’t want to mess with Mallet, a generally malicious attacker.

You’ll have to set up three of these entities: Alice, Bob, and Celie. First, you’ll have to set up Celie, the certification authority. Then, you’ll set up Alice, who will use Celie to authenticate her certificates. Finally, you’ll present the certificates to Bob, who will install them in his browser.

You’ll need some tools to complete these tasks. To manage keystores, you’ll need the keytool program that comes with the JDK. If you have installed your JDK correctly, you should be able to just run keytool at the command prompt. Because the software included with the JDK can create only self-signed certificates, you’ll also need to incorporate additional software that can sign certificates. OpenSSL is an excellent package for this purpose, so you’ll be using it in this article’s examples.

Celie, the Certification Authority
The instructions for setting up Celie assume that you have installed OpenSSL on your machine but haven’t changed its configuration. You’ll need to configure OpenSSL to allow Celie and Alice to belong to different organizations, which you can do by editing the configuration file openssl.cnf. Change the following line:

policy		= policy_matchto this:policy		= policy_anything

Once OpenSSL is set up, create the following directory structure:

demoCA           (directory)demoCA/private   (directory)demoCA/newcerts  (directory)demoCA/index.txtdemoCA/serial

The file index.txt should be empty, and the file serial should contain only the string ’01’. (Note to Windows/DOS users: this file must not have a newline at the end.)

Next, you need to generate a self-signed certificate. This is a certificate that attests to Celie’s identity, and which she signs herself. You do this with the following command:

openssl req -x509 -newkey rsa:512-keyout demoCA/private/cakey.pem -out
 demoCA/cacert.pem -passout pass:capass

Author Note: Many of these commands will be too long to fit on one line. Don’t be fooled by the fact that they take up multiple lines.

When you run this command, it will ask you for some personal information. Assume the role of Celie and enter her information:

Country Name (2 letter code) [AU]:USState or Province Name (full name) [Some-State]:New YorkLocality Name (eg, city) []:New York CityOrganization Name (eg, company) [Internet Widgits Pty Ltd]:Celie's Security ServicesOrganizational Unit Name (eg, section) []:Authentication DepartmentCommon Name (eg, YOUR name) []:CelieEmail Address []:[email protected]

This creates a file called demoCA/private/cakey.pem, which contains Celie’s private key. Keeping this file secure is crucial to the success of Celie’s business?if it gets out, all the certificates she has issued become worthless. Thus, a password protects this file. You specify the password on the command-line using the pass option. You also could have the program prompt for the password?which is safer?by leaving it off the command line. For this exercise, use the password capass.

The command above also creates a file called demoCA/cacert.pem, which is Celie’s self-signed certificate. More precisely, it is a copy of her public key that has been signed by her private key. This way, anyone can verify that she signed it herself. Youll use this certificate in the next few sections.Alice needs to get herself a signed certificate. The first thing she needs to do is generate a public/private key pair for herself?the first step when using public-key cryptography. If she already has these keys, then she can skip this step. Otherwise, carry out this command, using keytool from the JDK:

keytool -genkey -alias userkey -keystore user.keystore -keyalg rsa
 -dname "CN=localhost, OU=Online Division, O=Alice Inc, L=Los Angeles, S=California, C=US"
 -storepass userpass -keypass userpass

This command generates a key pair and stores it in the file user.keystore, which is locked with the password userpass. It also specifies information about Alice (her organization, city, and state). Note also that it specifies localhost as the hostname. In a real situation, the hostname would be something like alice.com, but since youre going to run your server locally, you need to use your local hostname. For the value of CN, use the name of the machine on which the Web server is running.

Now that Alice has a key pair, she needs to get her key signed by Celie. To do this, she must generate a Certificate Signing Request (CSR). A CSR is a file that is sent to the certification authority for signing; it contains the public key that needs to be signed in a special format.

The following command generates the CSR in a file called user.csr:

keytool -certreq -alias userkey -keystore user.keystore -storepass userpass
 -keypass userpass -file user.csr

After generating the CSR, Alice must send it to Celie. In addition, Celie is likely to require that Alice verify her identity in a more traditional way. She might require that Alice fill out forms, provide photocopies of identification, or even call her on the phone and answer identifying questions. The exact details of this process are up to Celie.

Celie Signs Alice’s Certificate
Celie has just received a CSR from Alice. She has reviewed the forms that Alice sent by snail mail and even talked with her over the phone. She’s convinced Alice is who she says she is, so she decides to sign Alice’s certificate. She does this with the following command:

openssl ca -in user.csr -out user.crt -notext -passin pass:capass

This command results place the signed certificate in the file user.crt. The command then prints out information about the request and asks Celie if she wants to go ahead and sign it. Actually, it asks twice to be safe:

Sign the certificate? [y/n]:y1 out of 1 certificate requests certified, commit? [y/n]y

Celie sends this certificate to Alice. She also sends Alice her self-signed certificate (in the file cacert.pem), because Alice is going to need it. Note that Celie’s private key is password-protected. Again, you can specify the password on the command line, or you can have the program prompt for it.

Alice Imports the Certificates
Alice now has the signed certificate (in the file user.crt) and Celie’s self-signed certificate (in cacert.pem). She first must import Celie’s self-signed certificate into her keystore user.keystore:

Queriekeytool -import -alias cacert -file cacert.crt
 -keystore user.keystore ?storepass userpass

First, keytool will ask for confirmation:

keytool -import -alias cacert -file cacert.crt -keystore user.keystore -storepass userpassOwner: [email protected], CN=Celie,
 OU=Authentication Department, O=Celies Security Services,
 L=New York City, ST=New York, C=USIssuer: [email protected], CN=Celie,
 OU=Authentication Department, O=Celies Security Services,
 L=New York City, ST=New York, C=USSerial number: 0Valid from: Wed Oct 30 17:23:08 EST 2002 until: Fri Nov 29 17:23:08 EST 2002Certificate fingerprints:	 MD5:  55:FA:3A:DC:1C:32:53:28:A2:A5:5A:96:C3:77:02:E4	 SHA1: B6:E2:0E:7B:A6:AC:9E:49:E5:1B:78:41:BC:C3:2D:FC:8E:36:8B:4ATrust this certificate? [no]:  yesCertificate was added to keystore

Then, she can import her own certificate (the one Celie signed for her):

sinfo (Records=1, Time=16ms)SQL = SELECT contentkeytool -import -file user.crt -keystore user.keystore
 -storepass userpass ?alias userkey

Alice is now equipped with the required certificates. She should configure her Web server to use user.keystore as its certificate repository. If the server requires the keys in a different format, she should use a conversion of user.keystore.

If you are using THTTPSD (click here for instructions regarding installing and running THTTPSD), you can configure it to use user.keystore by editing the thttpsd.cfg file. Set the keyfile parameter to point to user.keystore. The thttpsd.cfg file also has a password (userpass), which should be specified for the passphrase configuration variable. (Listing 1 includes the source code for THTTPSD, and Listing 2 shows the sample configuration file.)

Alice now is ready to start her server. If you’re using THTTPD, you can start it like this:

java THTTPSD

The server side is ready at this point, but Bob isn’t. He’s about to visit Alice’s secure Web server. He’ll get the warning message shown in Figure 1. (All figures in this section are taken from Mozilla 1.2b and apply as well to Netscape 7.0.)

Figure 1: Browser Unable to Verify the Identity of the Server

Hmm, what’s going on? Bob clicks on the Examine Certificate button, and he sees the contents of the certificate that came from the server, as shown in Figure 2.

Figure 2: Contents of the Servers Certificate

Note that the certificate indeed belongs to Alice and is indeed signed by Celie. Everything seems to be in order, so what’s the problem? Why the holdup? This glitch happens because Bob doesn’t have a copy of Celie’s self-signed certificate. Remember, Celie isn’t one of the big, famous certification authorities like VeriSign or Thawte. If she were, her certificate would ship with all major browsers. But she’s not, so Bob is going to have to install her certificate himself.

This isn’t an indication of Alice’s cheapness; Alice probably had a very good reason for using Celie. In the context of a company intranet, for example, internal Web servers quite possibly could be authenticated by an internal, company-wide certification authority.

Bob Downloads Celie’s Certificate
Luckily, recent browsers make installing a new trusted root certificate very easy?almost too easy since installing just any old root certificate is not a good practice. Celie can put her certificate on her Web site. She should rename it with a .crt extension because most Web servers understand this to be the suffix for certificates of this kind. The URL for the certificate will be something like http://celie.com/certificates/cacert.crt. When Bob goes to this URL, he’ll see the dialog box shown in Figure 3.

Figure 3: Downloading a Certificate

All Bob has to do is click on Trust this CA to identify web sites and press OK. With that, the certificate is installed. (Click here for instructions on installing Celie’s certificate on browsers other than Mozilla.) Now Bob’s browser knows about Celie. It trusts Celie, and therefore it will trust Alice. When he directs his browser to https://www.alice.com/, it lets him through without a peep.

One Certificate Does It All
As you can see, this process has a number of steps. However, remember that you did a lot in this one article:

• Set up a certification authority
• Configured a secure Web server
• Configured a Web browser to talk to the secure Web server

Now that this infrastructure is in place, it’s a snap for your users to configure their browsers to use your secure Web servers. Installing the certificate once is a lot more efficient than having to contend with a warning dialog every time a new server is added to the system. That one certificate can serve an entire organization for as long as necessary.

Installing instances of secure servers also is easier. You can use the in-house certification authority to sign certificates for each server you want to set up. If done in-house, it’s free. So you don’t have to think twice about setting up as many servers as necessary.