| apr98.tar |
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:
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.
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., gfibbers.intuit.com). 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.
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:
-----BEGIN NEW CERTIFICATE REQUEST----- MIIBJTCB0AIBADBtMQswCQYDVQQGEwJVUzEQMA4GA1UEChs4lBMHQXJpem9uYTEN A1UEBxMETWVzYTEfMB0GA1UEChMWTWVs3XbnzYSBDb21tdW5pdHkgQ29sbGVnZTE A1UEAxMTd3d3Lm1jLm1hcmljb3BhLmVkdTBaMA0GCSqGSIb3DQEBAQUAA0kAMEYC QQDRNU6xslWjG41163gArsj/P108sFmjkjzMuUUFYbmtZX4RFxf/U7cZZdMagz4I MmY0F9cdpDLTAutULTsZKDcLAgEDoAAwDQYJKoZIhvcNAQEEBQADQQAjIFpTLgfm BVhc9SQaip5SFNXtzAmhYzvJkt5JJ4X2r7VJYG3J0vauJ5VkjXz9aevJ8dzx37ir 3P4XpZ+NFxK1R= -----END NEW CERTIFICATE REQUEST-----
Copy the CSR and paste it in the edit box provided.
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.
Now that you have enabled SSL, users must use https instead of http to access your server. For instance, instead of http://gfibbers.intuit.com they will have to use https://gfibbers.intuit.com. 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 https://gfibbers.intuit.com:4001 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: Verisign: http://www.verisign.com Verisign Digital ID Center: http://digitalid.verisign.com
Verisign Information Desk: Apache-SSL: http://www.apache-ssl.org/ 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 (http://www.taos.com), 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 btanaka@well.com or http://www.well.com/~btanaka. Brian would like to thank Patrick Slaney for his invaluable input.
|