Secure Sockets Layer: Protect Your E-Commerce Web Site with SSL and Digital Certificates

Johnny Papa

This article assumes you�re familiar with IIS

Level of Difficulty    1   2   3 

SUMMARYSecurity is one of the most important factors in the future growth of e-businesses. Making sure that communications remain secure between customers and the Web server is a critical issue.
      Secure Sockets Layer (SSL) is the standard that secure Web sites are built upon today. This article presents an overview of SSL-based Web security, explaining such fundamental concepts as digital certificates and their distribution, encryption, and the proper configuration of Microsoft Internet Information Services (IIS). Acquiring a certificate, installing it, and configuring IIS for SSL are outlined in a step-by-step process.

t seems that everyone is concerned about the security of transactions over the Internet—especially when the success of so many e-commerce companies depends on it. Today, Secure Sockets Layer (SSL) is the standard technique for protecting Web communications. SSL is compatible with all recent Web browsers, including Microsoft® Internet Explorer 3.x and later. On the server side, SSL certificates are compatible with most Web servers, including Microsoft Internet Information Services (IIS).
      I'll start out by explaining the basics of SSL, certificates, and encryption. Then I'll introduce you to the two kinds of digital certificates used by SSL: root certificates and server certificates. Finally, I'll show you how to get the certificates and set up your IIS-based Web site to provide secure transactions using SSL.

SSL: The Big Picture

      First of all, when I refer to a secure server in this article, I'm really referring to a Web server (such as IIS) that will use SSL. SSL is the security method used to transmit sensitive information like credit card numbers and online banking data over the Internet.
      Basically, SSL is the technology used to encrypt and decrypt messages sent between the browser and server. By encrypting the data, you protect messages from being read while they are transferred across the Internet. SSL encrypts a message from the browser, then sends it to the server. When the message is received by the server, SSL decrypts it and verifies that it came from the correct sender (a process known as authentication).
      SSL consists of software installed on both the browser and server. If you are using a recent version of any of the major browsers, support for SSL is built into the browser. But you still need to activate SSL on the browser and install it on your Web server. Several companies, including Verisign, SSL.com, and Equifax offer SSL encryption and authentication tools. Verisign's digital certificates, for example, are already installed in most recent versions of the major browsers.
      You've probably heard of 40-bit and 128-bit encryption. This actually refers to the length of a "key" that is generated by every encrypted transaction. The longer the key, the more difficult it is to break the encryption. So why not use 128-bit encryption in all cases? That would be ideal, but while most browsers support both 40-bit and 128-bit encryption, if you require transactions to be conducted internationally you may be restricted to 40-bit encryption under certain circumstances. Since 128-bit encryption offers much better security, go for it if you have a choice. See the sidebar titled "New Security Regulations" for more information.

Untangling Digital Certificates

      Before I go much further, let me explain how digital certificates and root certificate authorities fit into the SSL picture. Digital certificates, more commonly just called certificates, are used by the SSL security protocol to encrypt, decrypt, and authenticate data. The certificate contains the owner's company name and other specific information that allows recipients of the certificate to identify the certificate's owner. The certificate also contains a public key used to encrypt the message being transported across the Internet.
      As I mentioned earlier, SSL uses two kinds of certificates: root certificates and server certificates. Root certificates are installed on the browser, and server certificates exist on the Web server. A root certificate tells the browser that you will accept certificates signed by the owner of the root certificate. For example, if you install a root certificate signed and issued by Blue Sand Software into your browser, you will be able to authenticate and decrypt messages that were sent from Blue Sand Software. This is vital to ensuring a secure transaction.
      A server certificate is installed on the Web server. It works much like the root certificate and is in charge of encrypting the messages sent to browsers and decrypting messages received from browsers.
      So how do you get these certificates? You'll need to go to the Web site of one of the various certificate authorities and submit a Certificate Signing Request (CSR). After you submit the CSR, the certificate authority will verify that your business is valid and issue you a server certificate. You then install the server certificate on the Web server. But keep in mind that any user who wants to use your secure Web server must have the root certificate from the certificate authority installed on their browser as well. Most browsers have a Verisign root certificate preinstalled, so if Verisign is your server certificate authority, you're ready to go.

Breaking Down Encryption

       SSL handles the scrambling of messages for you so that only the intended recipient can read it. The encryption/decryption process goes something like this:

1. The user browses to the secure Web server's site.
2. The user's SSL secured session is started and a unique public key is created for the browser (using the certificate authority's root certificate).
3. A message is encrypted and then sent from the browser using the server's public key. The message is scrambled during the transmission so that nobody who intercepts the message can make sense of it.
4. The message is received by the Web server and is decrypted using the server's private key.

      The process of SSL encryption relies upon two keys: the server's public key and private key. The private key only exists on the Web server itself and is used by the Web server to encrypt and decrypt secure messages. The public key exists on any client computer that has installed a root certificate for that Web server. Once the public key is installed, the user can send encrypted messages to and decrypt messages received from the Web server. Figure 1 shows this process. Just to be extra safe, the keys are discarded once the transaction's session ends.

Figure 1 Asymmetrical Encription using SSL

      SSL doesn't prevent the message from being intercepted. However, it does make the message useless to the rogue interceptor. In other words, someone could capture the message on its way to the secure Web server, but could not decrypt it because they do not have the server's private key.
      The encryption process can be either symmetric or asymmetric. Symmetric encryption uses a single key by both parties to encrypt and decrypt secure messages. The problem is that the key itself has to be passed along as part of the conversation. This leaves the key, with its power to decrypt the messages, easy prey to a seasoned cracker. Because of this downfall, asymmetric encryption was welcomed with open arms. Since the keys are never transported with asymmetric encryption, there is never a risk of them being stolen by a rogue third party. As you can see in Figure 1, using asymmetric encryption lets you tightly and securely transact business via the Web.
      With asymmetric encryption, why can't someone with the root certificate steal a secure message and decrypt it themselves? Well, each session key (or public key) generated by the root certificate is unique. So even if the cracker has the same root certificate installed on their browser, it will do them no good in their attempts at decrypting the message. In fact, even the originating browser of the encrypted message can't decrypt it. Only the Web server with the appropriate private key can decrypt the message.

Obtaining Certificates

      To set up SSL support for your IIS-based Web site, you'll start out by getting the appropriate digital certificates from a certificate authority. When you go to a certificate authority's Web site and begin the process of applying for the certificates, the steps are relatively straightforward. You'll need to fill out information about your company, who to contact, and valid documentation for your organization. Usually the articles of incorporation will suffice for the certificate authority to approve your certificates. This process may seem tedious, but it is necessary for the certificate authority to verify that your organization is legitimate.

Generating a CSR File

      Your certificate authority will request that you provide it with a CSR file. This is an encrypted file containing information about your company and Web server. The certificate authority will use the CSR file to generate and validate certificates for you.

Figure 2 Selecting the Web Site of an IIS Server

      The process of generating a CSR from IIS is quite simple. First, open the Internet Services Manager and select the Web site you want to secure using SSL (see Figure 2). Click on the Key Manager toolbar button to display the security properties for the Key Manager (see Figure 3). Now, right-click on the WWW icon and select Create New Key from the context menu.

Figure 3 Key Manager Dialog

      The Create New Key wizard appears, as shown in Figure 4. I left the name of the file alone, but you can name it anything you want. This will be your CSR file once you've run through the wizard.

Figure 4 Assigning the CSR File

      Press the Next button. In the next dialog, enter a name for the key (use whatever name you want), a bit level, and a password (as shown in Figure 5). Remember the password because when the certificate authority sends you back the certificate information, you'll need the password to install it on IIS.

Figure 5 Assigning Key Name, Password, and Bit Length

       Select the Next button to move on to the next dialog. Here you'll need to enter your company's name and an organizational unit. This can be anything you like, but keep in mind that if you request multiple certificates, you'll need to alter the organizational unit name with each submission. You'll also need to enter the Common Name of the certificate. This must be the domain name of the Web server.
      Click the Next button to go to the next wizard screen. Enter the country, state (spelled out completely—no abbreviations), and city. Select Next, fill out the contact information, and click the Finish button. This will generate the CSR file for you. At this point the Key Manager dialog will display a key icon with an orange slash through it. This signifies that you haven't finished setting up SSL on this Web server.
      Now go to your certificate authority's Web site and follow their directions to request a certificate. When they ask you for the CSR file, submit the contents of the CSR file you just created. Probably the easiest way to do this is to open the file using Notepad, copy its contents, and paste the data into the authority's request form. The CSR data will look something like the text shown in Figure 6.

Installing the Certificate

      Assuming that the certificate authority grants your request for a new digital certificate, they will send you a file via e-mail. This is your server certificate. Save the certificate to your server, and follow these steps to install it in IIS:

1. Open the Key Manager dialog on your Web server.
2. Right-click on the key with the orange slash through it and select Install Key Certificate from the context menu.
3. Select the file that the certificate authority sent to you, and enter the password when prompted for it.
4. Follow the wizard's instructions. Make sure you commit all changes when you are asked to do so by the wizard.

Congratulations! You've just installed the certificate on your Web server.

Check those IIS Settings

      Now that the certificate is installed on your IIS server, you need to enable SSL on your Web site. To do this, you'll need to open the Internet Services Manager and right-click on the Web site you want to secure. Select Properties from the context menu. Then go to the Directory Security tab and click on the Edit button. The Secure Communications dialog should appear, as shown in Figure 7. Make sure you select the "Require Secure Channel when accessing this resource" option. At this point you can customize the settings for your Web server.

Figure 7 Selecting the Secure Communications Dialog

      If you click on the Encryption Settings button, you can specify whether you want to use 128-bit or 40-bit encryption. As mentioned earlier, for international use you may want to stick with 40-bit encryption. However, if you are concentrating on users within the U.S., you should use the 128-bit encryption since it is much more secure.
      You have three options in specifying the type of client certificate authentication. The first, Do not accept Client Certificates, prohibits access to the Web site to users trying to access the resource using a client certificate. Accept Certificates allows all users with or without a certificate access to the Web site. Require Client Certificates allows only users with a certificate access to the Web site. All others are prohibited from accessing the Web site. Choose the setting that meets your security needs best.

Finishing Touches

      When you code your Web site to redirect to the secure site (or secure portion of a site), make sure you precede the URL with the proper protocol designation. You'll be using the HTTPS protocol for the secure portions of the Web site, so be sure to update all of your code to reflect this. For example, you'll no longer go to https://www.bluesand.com/ShoppingCart. Instead, you'll be going to https://www.bluesand.com/ShoppingCart.

For related articles see:
Security Briefs in this issue
For background information see:
Adding Windows NT and Internet Information Server Security Features
Securing Your Site Against Intruders

Johnny Papa is the vice president of IT at MJM Investigations, a leading private investigation firm in Raleigh, NC. He is the author of several magazine articles and books, including* Professional ADO 2.5 RDS Programming with ASP 3.0 *(Wrox, 2000), and can be found presenting at various industry events. You can reach him at john@lancelotweb.com.

From the April 2001 issue of MSDN Magazine.