Controlling access (implementing authentication and authorization) is one part of having a secured site. To secure your site fully, you need to encrypt the transmission of information between the client and the server. The .NET framework supports a large and growing set of cryptographic methods. The most common methods are RSA, named after Ronald Rivest, Adi Shamir, and Leonard Adelman, who first published the algorithm in April 1977. RSA is an asymmetric encryption. It uses a public key/private key algorithm whereby encrypting a message with the public key creates a message that can be unencrypted only by the private key. Therefore, as an individual or entity, you can freely release your public key, knowing that by maintaining the secrecy of your private key, you are the only one who can unencrypt messages encrypted with your public key. The most popular implementations of RSA encryption include Pretty Good Privacy (PGP), the GNU Privacy Guard (GnuPG or GPG), and Secure Sockets Layer (SSL), supported by most modern browsers.
To use SSL, you need a public key. You can obtain a public key from various certificate authorities, which can verify that a key actually belongs to an individual or organization. SSL does not require the client to have a certified public key; instead, when you browse a site using SSL, the server provides its public key to the browser, which verifies the key with the certificate authority.
RSA does have one drawback—it's relatively slow, too slow to support sustained Internet serverbrowser communications. Therefore, the browser generates a new encryption value that both the server and the browser will use to encrypt subsequent messages using a faster encryption algorithm, typically a symmetric encryption algorithm in which both the message sender and the message recipient must know the encryption key. The browser encrypts the new symmetric key value with the server's public key and returns the symmetric key to the server. The server uses its private key to decrypt the symmetric key provided by the browser. Then both server and browser have a symmetric encryption key that they can use to encrypt subsequent messages.
If you're involved in transactions such as e-commerce, medical, or financial, in which people provide credit card numbers, Social Security numbers, private medical data, or any other data that must remain private, you should obtain an encryption key from a recognized certificate authority and use SSL for the pages in your site that transmit sensitive information. You must combine SSL with authentication and authorization techniques to ensure the privacy of the information—it does you no good to encrypt information if you can't be reasonably sure of the client's identity.
Certificate authorities can provide SSL certificates on a per-server or per-site basis. Some prominent authorities are Verisign (http://www.verisign.com) and Thawte (http://www.thawte.com). Pricing is based on the number of certificates and servers. At the time of this writing, Thawte provides a test certificate good for 30 days that makes it easy to test SSL with your server. After installing the certificate, you can enforce SSL by changing the IIS security settings for any application, or for the root Web (all applications).
Note Using SSL slows down your server and your application to some degree because the server (and the browser) must encrypt and decrypt requests and responses.
The first step in obtaining a certificate is to generate a certificate request. IIS 5 or higher can generate the request for you. Launch the Default Web Site Properties dialog, select the Directory Security tab, and click the Server Certificate button. Follow the IIS Certificate Wizard's directions to generate the certificate request. Although the screens differ in IIS 6, you'll have little trouble following the procedure in either version.
The first time through the wizard, select the Create a New Certificate option (see Figure 18.10).
The request itself creates a text file that you'll need to get a certificate from your selected certificate authority. In turn, the authority provides a text file that contains the certificate (see Figure 18.11). Select the delayed request option on the next wizard screen.
You must provide a name and select the bit length for the certificate request. Shorter bit lengths are faster, but longer bit lengths are more secure (see Figure 18.12). Don't leave the default name—pick a specific name.
developing in the U.S. and you deal with international clients, you should become familiar with these restrictions.
The next three screens ask for your organization, organizational unit, server or site's fully qualified domain name, and location. When users view your certificate, they'll see some of the information you enter into these wizard screens, so make sure the information is correct and reflects your company policies.
The final screen requests that you enter a filename for the new certificate request. Give the request a name identifying it as a request for this server (requests are not transferable), and click the Next button to create the request and finish the wizard (see Figure 18.13).
You'll see a summary screen. Check the information carefully. Certificates are expensive, and you can't change them after making the request.
The text file that the wizard saves contains your certificate request. Your selected certificate authority will process the request and return another text file containing the certificate—typically via e-mail or on site in a text field. Both the request and the certificate look similar to the following:
--BEGIN NEW CERTIFICATE REQUEST--
a/kPi5FK8MAHILb37PfwVdd4zT4 6If39eY+FlwA8/PThp+c0T8 5bAgMBAAGgggFT
You cut and paste the returned certificate to a text file on your server. By convention, certificate files have a .cer extension, even though they're simple text files.
To install the new certificate, restart the IIS Certificate Wizard. The wizard tracks pending requests. This time, select the Process the Pending Request and Install the Certificate option (see Figure 18.14).
The wizard will ask for the name of the certificate file. Enter the name of the CER file you saved from the certificate authority, not the name of the certificate request file.
After installing the certificate on your server, you can make any virtual directory use SSL by requesting pages using the HTTPS protocol rather than the HTTP protocol.
Warning Make sure you keep a copy of the returned certificate. The process of installing the certificate alters the CER file. You cannot install the same CER file twice.
You should use SSL for any pages that transfer sensitive information such as account numbers, passwords, financial information, or Social Security numbers over the network. For example, you should use SSL for login pages. If you don't, the transmission may be intercepted by anyone between you and the client.
Was this article helpful?