Cover V07, I04


Acquiring and Installing a Server Certificate

Brian Tanaka

As the demand for "secure Web browsing" grows, so does the probability that you'll need to administer an SSL-enabled Web server. In this article I will explain one critical element of configuring an SSL-enabled Web server: acquiring and installing a server certificate.

Server Certificates and SSL

SSL is too complex to be explored in detail in a how-to article such as this. However, I will briefly outline the basic concepts. Please refer to resources mentioned at the end of this article for more information.

When using a Web browser just to view Web pages, I am not terribly concerned about security. However, if I exchange sensitive data (such as credit card information) with a Web server, I am very concerned about it. Specifically, I want to know that:

I am exchanging information with the correct server rather than an impostor, and

The data is encrypted while in transit.

In cryptographic terms, I want "server authentication" and "data confidentiality." Secure Sockets Layer (SSL) is designed to provide these two security features. It also addresses other security concerns, but these are two of the most important.

SSL-enabled Web servers must have a server certificate. Roughly stated, a server certificate is a form of digital identification and is issued by a Certificate Authority (CA). A server certificate requires a key pair. In "public key cryptography" (which SSL uses) there are two digital keys: a public and a private key. Together they form a key pair. What is encrypted with one key can be decrypted only by the other key. As its name implies, the public key can be made publicly available. The private key must remain secret.

To summarize, SSL is intended to increase security between Web clients and Web servers, and you need a server certificate to use it.

To acquire a server certificate you need to:

  • Generate a key pair and Certificate Signing Request (CSR) on your server
  • Submit the CSR to a Certificate Authority (CA)
  • Install the server certificate
  • Enable SSL on your Web server

I will explain these steps in the remainder of this article.

A Quick Word About Cost

The monetary cost of using SSL is sometimes overlooked. Before you begin the process of acquiring a server certificate, please note that the CA will probably charge for their services. You should research the current cost of CA services and make sure the cost is within your organization's budget. Also note that the costs are recurring.

Generating the Key Pair

A key pair is generated by using the interface provided by your Web server software. Let's look at a specific example using Netscape Enterprise Server 3.0. The following steps are adapted from the Netscape Enterprise documentation, which should be consulted for more detail.

  1. Log in as root.
  2. cd to bin/admin/admin/bin in the server root directory.
  3. Run ./sec-key.
  4. You will be prompted for an alias name. The alias will refer collectively to the key pair and the certificate file. This will allow you to operate on them as a set and also allow you to have multiple sets. It is common practice to name this alias after the server. So, in my example, I name it "gfibbers." My key pair file will be <server_root>/alias/gfibbers-key.db.
  5. In the next step, you will be prompted to type keystrokes for a while in order to add some unpredictability to the random number used to create your keys. Do so until the progress meter stops.
  6. Next, you will be prompted for a password for the key pair file. It is important to pick a strong password. A strong password will not contain any words from any language, will be at least eight characters long, and will contain upper and lowercase letters as well as non-alphabetic characters such as punctuation marks. Don't forget this password, because you will use it each time you start your SSL-enabled Web server.

Now you're done. The key pair file has been created and stored on disk.

It is extremely important to make a backup copy of your key pair and password. It is equally important to secure both copies. If you lose or divulge your private key or password, you will need to revoke your certificate and start over. Next we'll create the CSR.

Generating the CSR

Think of the CSR as an application for a certificate. You will submit the CSR to the CA, which in turn will issue a server certificate to you. There are a number of CAs in the world, but I'll use VeriSign for the examples in this article.

Before going any further, it is wise to gather the information necessary for the next steps. There are two groups of information you will need: one for the CSR generation and one for VeriSign's application process. Other CA's procedures should be similar, but you should get information about the application process that is used by the CA you select.

For CSR Generation

Key Pair File Password - You already know this, because it is the one you chose when you generated the key pair.

Requestor name - That's you!

Telephone number - Your phone number. This is the number VeriSign will use to contact you by voice before issuing your certificate.

Common name - The fully qualified domain name of your server (e.g.,

Email address - Your email address. You might consider creating a mail alias for this purpose so that even if the person responsible for certificate management changes, the email address on file at VeriSign will still be correct.

Organization - In my case, it would be Intuit Inc.

Organizational unit - You can use this field to further distinguish the group that is using the certificate. For instance, "Online Commerce Division" or "Information Services". Choose wisely; this information will be a part of your certificate and is viewable by client-side users.

Locality - Your city.

State or province - Your state. Note that you should not abbreviate.

Country - Use the two-character ISO format country code. (e.g., US, NL)

For VeriSign

Your server software vendor - In this example, it would be Netscape.

Challenge phrase - Pick a phrase that's easy to remember but hard for someone else to guess. You'll use this if you need to request VeriSign to revoke the certificate in the future.

Contact information - This can be a bit tricky. You need three contacts: a technical contact, an organizational contact, and a billing contact. The technical contact must be authorized to maintain the server. In most cases this will be you, the system administrator. The organizational contact must be an employee of your organization and be "authorized to make binding agreement" to Verisign's legal agreement. This person should be different from the technical contact and is often an official corporate officer. The billing contact person will receive invoices and can be the same as either of the other two contacts.

How you will pay for the Digital ID - Credit card, purchase order, or check. Credit card is the fastest.

Your Dun & Bradstreet D-U-N-S Number - This optional item also speeds up your order with Verisign, because they use it to verify your corporate identity.

Now that you've collected all of the above information, you are ready to generate your CSR. As in the case of the key pair generation, your Web server software should provide a way to generate the CSR. Let's look at an example using Netscape Enterprise Server 3.0. Refer to the Netscape Enterprise documentation for further details.

  1. Use your Web browser to connect to the Server Administration page. In my example, I would connect to: Use the port you specified as the administrative port when you originally installed your server.
  2. Choose Keys & Certificates. From that page, choose Request Certificate.
  3. A form will be presented to you. On this form, specify whether this is a new certificate or a renewal of an existing certificate. In this example, I'm applying for a new one, so I'll check that radio box.
  4. The next part of the form has a link to a "list of available certificate authorities." You may wish to view that page for an idea of what's available. For this example, I've already decided on VeriSign.
  5. The next section allows you to submit the request to your CA either via email or via a Web site. However, VeriSign does not want the CSR sent to them via email, because they want you to complete the enrollment procedure on their Web pages, and the "submit via CA URL" method assumes that the CA is using Netscape Certificate Server. This is useful if you are submitting, for example, to an in-house CA using that particular software, but that isn't the case here. What I really want to do is to output the request to a file. So, in order to get the file, I select "CA email address", but I fill in the address field with my own address: When I'm done with this form, the CSR will come straight to me.
  6. Select the alias you created when you generated the key pair and enter the password you defined earlier.
  7. Fill in the remaining fields with the information you gathered beforehand (e.g., your name, phone number, server's common name, etc.).
  8. When you've made sure the values are correct, click on the OK button at the bottom of the page. A subsequent page will ask you to verify that the information is correct.
  9. Since I specified my email address as the destination, I will receive the CSR in my mailbox. I'll save it to a file for use in the next section.
Submitting the CSR to a Certificate Authority

Now that you have the key pair and CSR, you're ready to submit the CSR to a CA. Since the CA is attesting to the binding between an identity and a public key, it must first satisfy itself that you are who you claim to be. When the CA is satisfied that everything is in order, it will issue you a certificate. The certificate will contain server identity information, your public key, other information (e.g., validity dates), and the CA's digital signature. There are a number of ways to submit the CSR, but let's look at a specific example that fits with our earlier steps.

VeriSign provides a Web front-end to their CSR submission procedure. Here's how to use it:

  1. Aim your trusty Web browser at: This is the main page of the VeriSign Digital ID Center. From this page you can apply for a digital ID, manage existing IDs, check on the status of your request, check the validity of an ID, etc.
  2. Click on Enroll.
  3. In the Organizations column, click on Web Servers.
  4. Choose the statement that best describes you. In this example, "I want a Secure Server Digital ID to run SSL on my server."
  5. Now select the proper server software vendor. In this example, I'll choose "Netscape." On the next page, I'll choose the correct Netscape product.
  6. The next page provides an overview of the process. Part of the page describes what information you should acquire beforehand. Since you've already gathered all of the information, you're ready to go. It is wise to read over this page anyway, because it may contain important information that was not available or required at the time this article was written. Click on the Begin button.
  7. You're ready to submit the CSR. Open the mail message with the CSR in it. A CSR looks like this:

Copy the CSR and paste it in the edit box provided.

  1. 8. The next page will show the values of the fields you filled in when you generated the CSR. Double-check them.
  2. 9. Fill out the rest of the fields with the information you gathered beforehand.

When you're done filling out the necessary forms, you will need to wait for the CA to verify your information. The CA may contact you by phone to make last minute verifications before releasing your certificate. When all is in order, the server certificate will be issued to you. Usually it is sent via email to the address you specified earlier. When you receive it, you are then ready to install the certificate on your server and enable SSL.

Installing the Server Certificate and Enabling SSL

As in the case of generating the key pair and generating the CSR, your Web server vendor will most likely provide a way of installing the certificate and enabling SSL. Let's continue our example using Netscape Enterprise Server 3.0. Additional information is available in the Netscape Enterprise documentation.

  1. Use your Web browser to connect to the Server Administration page. In my example, I would connect to (Use the port you specified as the administrative port when you originally installed your server.)
  2. Choose Keys & Certificates. From that page, choose Install Certificate.
  3. A form will be presented to you. On this form, specify whether this is a new certificate or a renewal of an existing certificate. In the example, I'm applying for a new one, so I'll check that radio box.
  4. Select This Server.
  5. Select Message Text (with headers).
  6. Paste the certificate issued to you by the CA in the edit box. Make sure that the text of the certificate is not mangled in any way. I once had trouble with spaces appended to each line. If the text is corrupted, the process will fail. Also, be sure you've included the "Begin Certificate" and "End Certificate" lines.

  7. Select the alias you created when you originally generated the key pair.

  8. Click on OK.

  9. You will be asked whether or not you want to add the certificate. Click on Add. Now the certificate will be stored in the file <server_root>/alias/<alias>-cert.db. Since, in this example, my alias is "gfibbers", my certificate will be stored in <server_root>/alias/gfibbers-cert.db. Now that the certificate is installed, you can proceed to the next step and turn on SSL.

  10. Go back to the main Server Administration page and click on Admin Preferences.

  11. Click on Encryption On/Off.

  12. Use the radio button to turn encryption on.

  13. Select the alias you created earlier. In this example, I'll select "gfibbers".

  14. Click on OK. You can now set any security preferences you want.

  15. When you're done, you must stop and start the Web server. Remember that you will be prompted for the key pair password when you try to start it.

Now that you have enabled SSL, users must use https instead of http to access your server. For instance, instead of they will have to use Also note that the standard port for SSL is 443. If you specified port 443, users do not need to specify it in the URL because it is assumed. But, if you chose some other port, they will need to specify that port in the URL. For instance, if I chose port 4001, then they will need to use to access the site.

Finishing Up

You may wish to change the parameters for SSL. For instance, you can specify which version of SSL to use (version 2 or version 3 at the time of this writing), specify which cipher suites to use, and so on. Consult your Web server software vendor's documentation for more details.

After turning on SSL, I like to test the Web server by comparing browser access via http and https URLs. When you successfully load a page via SSL, use your browser to view the certificate you installed. For instance, in Netscape Navigator, select Page Info under the View menu. The lower pane in the subsequent window will show the certificate information, including the length of the key, the distinguishing information about the server and the organization that controls it, who issued the certificate, the range of dates during which the certificate is valid, etc.

Note that certificates have a validity date range. The certificate is not valid before the starting date and after the ending date, and client software should reject it outside that range. Usually the operational period is one year, but it may differ. Because of this, add another item to your maintenance list: certificate renewal. Find out how your CA's renewal process works and be prepared to renew well in advance of the certificate's expiration date.

Your Web server is now SSL enabled. And because it never hurts to know more about the technology you manage, I refer you to the following resources for further reading.

Further Reading

Netscape's SSL Documentation:

SSL Documentation provided with Netscape Enterprise Server:
http://[yourhost]:[your admin serv port]/admin-serv/ \


Verisign Digital ID Center:

Verisign Information Desk:


Garfinkel, S. and G. Spafford. Web Security & Commerce. 1997. O'Reilly and Associates.

Garfinkel, S. and G. Spafford. Practical UNIX & Internet Security, 2nd Edition. 1996. O'Reilly and Associates.

About the Author

Brian Tanaka lives, works, and plays in the San Francisco Bay Area, and is a senior consultant with Taos Mountain (, a system administration consulting firm in the Silicon Valley. He has provided UNIX and NT system administration services for companies such as The Whole Earth 'Lectronic Link, Intuit Inc., and Silicon Graphics Inc. and can be reached at or Brian would like to thank Patrick Slaney for his invaluable input.