10 - Secure Transactions with IIS (HTTPs)

Create a secure server environment - Find out what adding the capability for a secure server can mean to your environment. You'll see what it brings to your server and how you can use it to better control information flow on your Intranet.
Apply for, and receive, a signed certificate for your server - You'll see how to work with a registration authority to obtain the digital certificate for your server, enabling the secured transactions capabilities of your system.
Implement the certificate on your system and learn what it means to the users of your system. - Putting the protection of a registered certificate into place on your server is the key to protecting information on your system. See how you go about creating the key, and how you implement it on your server.

The Web is, by definition, wide open in how it works with all of the different types of systems "out there." This means that, on the whole, your server needs to work at the lowest common denominator when working with requests from browsers. This also means that it's difficult to establish a secure transaction environment because you don't know what type of interaction you can have with the receiving end of the conversation.

This open environment means that, under normal circumstances, the information you send to a remote system is available to people on the network should they decide they want to listen in to your conversation. This can include form-based data, clear text passwords and much more. Much of the active research on the Internet is going into how to make the Web a better place to conduct business. This is also very applicable to your Intranet, as you'll likely be dealing with many of the same issues that relate to privacy of information. When you begin making more personal types of information available, things like personnel files and pay rates, you establish the need for secure communications at different locations on your server.

Digital certificates are based on the same technology as "Pretty Good Privacy" or PGP security. You have a digital signature, which appears to be a random block of letters, numbers, and symbols. The following block of text shows what the start of a signature block might look like:

MIIBrTCCARYCAQAwcDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldBU0hJTkdUT04x
EDAOBgNVBAcTB1JFRE1PTkQxEDAOBgNVBAoTB0VYQU1QTEUxDTALBgNVBAsTBFRP
VVIxGTAXBgNVBAMUEHd3dy5teWNvbXBhbnkuY28wgZ4wDQYJKoZIhvcNAQEBBQAD
gYwAMIGIAoGBDBku5DMBNnYZQI+cpitWsLGxMwf/mHl9t1flG05NoFrLJQcJKZbh
B9jAAWDCau7kD+usYd0C0tyTyhMkhg76/5Mqr8itZEhSF61OCb5+719abTy0sX7x
...

You'll see different ways to enable this security, and what it means to your organization, in this chapter. You'll also see how to create a server environment that will give you this added security measure so you can provide sensitive data to your legitimate users without fear of it being spied on by a third party.

Why Use Secure Transactions?

When you send information related to your Web service over the Intranet, it travels in ASCII format. This means that anyone who is savvy to ways of "spying" on transactions on the network is able to easily see the information that is being exchanged. By implementing a security layer on particular directories on your system, you control the transmission of information, and you can encrypt it to prevent other people from seeing discernible text.

Since it's likely that you'll be providing secure or confidential information on your Intranet, you're going to want to apply the security layer to the server. There are some key concepts about the secure transactions that you need to know and understand:

The people accessing your network must be using a browser that supports SSL. This means that some of the lesser-known browsers won't be able to work with your site's protected directories. They will still be able to work with "public" access information, however.
Implementing your secure server requires several steps. One of these steps, obtaining the certificate from the certificate authority, is completely outside your control. You need to plan on approximately two weeks for the Central Authority to fulfill your request and return a key to be installed at your site.
You can apply SSL control only to the Web server-based content. You cannot use SSL directly with FTP, although there are some ways to work around this, which you'll learn about later in this chapter.
Remember that SSL is a complement for, not a replacement of, NTFS security on your system. These technologies (SSL and NTFS) represent two different approaches to security. With SSL, you're controlling how the information is sent over the network. With NTFS, you're controlling access to the information. NTFS dictates whether the user can get to the pages in the first place.
You can protect directories on a case-by-case basis. You don't have to protect the entire site, though you may do so if needed. Protection of a directory protects its hierarchy when accessed from that virtual directory, but not from another directory. This seems a bit odd at first, but consider the following scenario:
- You create a virtual directory to MyDirectory, the name of which is Virtual1. You have set up this virtual directory to be secure. MyDirectory has two different subdirectories, sub1 and sub2.
- You create a second virtual directory, also pointed to MyDirectory, with the name of Virtual2. This access point is not secure.
- When you access Virtual1, information exchanged is secure, as it is if you're accessing the subdirectories under Virtual1 by way of Virtual1. In other words, the URL https://holodeck3/virtual1/sub1 is secure, since it's accessed through the Virtual1 access point.
- By contrast, when you access Virtual2, information is not securely transmitted. Also, if you're accessing http://holodeck3/virtual2/sub1, the non-secure aspect of the link remains.

This last item is extremely important, both from a point of implementation and a point of caution. The caution comes from the fact that you can provide unsecured access to content that you intend to be protected, undoing all of your hard work to provide the secure channel to the information. For this reason, Microsoft recommends that you maintain two distinct trees of information on your site. One tree should be for public, non-SSL information, and one should be for SSL-encrypted information.

Of course, there is an upside to this as well. To make your site more available to different types of browsers, you can offer both secure and non-secure access to information. There are many sites that offer a choice, when accessing their pages, of using the SSL connection or using a non-protected access method. To do this, you could have two different links on your pages taking the user into the protected areas, one that uses the SSL path and one that doesn't.

What's Happening Behind the Scenes?

The process of creating and using the secure channel of communications requires a few things behind the scenes. As you'll soon see, the server has a key that identifies it and indicates to the browser that it really is the server the browser thinks it is. The server and the client software exchange this key, enabling the client to use the key to decrypt information sent to it from the server.

Two processes open and maintain the secure channel. In the first, key information is exchanged. In the second, the protocol to front-end the HTTP service is established. This decrypts the information coming in from the client system before it hits the server applications. This makes the SSL completely transparent to the services that use it, a very important factor if it is to coexist without regard for the applications that it is protecting.

Once the request passes to the HTTP layer, the HTTP layer uses and responds to the information, giving the response back to the SSL layer. SSL encrypts the information and submits it to the TCP/IP layer for communication back to the client software. See Figure 10.1 for more information.

Fig. 10.1 - The SSL Layer encrypts and protects the information flow between the server and the client system.

After the secure channel is open and running between the server and the client, SSL's only function is to encrypt and decrypt the information flowing between the two. It makes the use of the secure channel completely transparently to the server.

On the client side, the SSL component is responsible for nearly the same process, that of encrypting and decrypting the information. The difference, of course, is that the SSL engine uses the key provided by the server to do this work, not a key that it maintains separately.

This is somewhat like giving someone a copy of your house key to watch your house while you're away. They have a key when they need it, but when their job is done, they no longer need the key, so they discard it (or return it to you).

Creating and Working with Digital Certificates

The process of creating the keys that your server will use involves several steps, as we've mentioned before. Certificate Authorities are in the business of authenticating you, the user of the keys. In essence, they're vouching for your nature. When a Central Authority issues a key, it's not so much that they are certifying your character, but they are indicating that the key you are using correctly identifies you to the client system on a completely unique and accurate basis.

Keeping this in mind, you'll quickly understand the small bit of red tape that accompanies setting up your server to be secure with the SSL techniques. The authority must ensure that the right party is receiving the certificate. In addition, since your key must absolutely, uniquely identify you, the issuing agency must make very sure they have the information they need to generate your key.

Generating Keys

First, you need to generate the request for the key. This is typically done over e-mail, and requires that you create a certificate request using a special utility provided with IIS. The utility, the Key Manager, is located on the Microsoft Internet Server menu. Figure 10.2 shows what this utility initially looks like when you start the process of generating keys.

Fig. 10.2 - The initial display for the Key Manager lists the different known servers on the current network.

The first thing you may have to do is make your server visible to the Key Manager utility. If you don't see the appropriate server listed in the dialog box, you'll need to add it. To do this, select Servers, and then Connect to Server. It prompts you for the name of the server to add to the list. You can indicate the server by computer name or by IP address. See Figure 10.3 for an example of this dialog box.

Fig. 10.3 - You can manage any number of servers from a single management workstation, balancing time spent and the hassle of implementing certificates with the need to work directly on the desired server.

When you give the utility the computer name you want it work with, it attempts to contact the server to ensure that it is accessible on the network. When the server has been added to the list successfully, you'll see it appear in the list of servers. If you receive a message "Unable to administer remote machine," double-check the computer name spelling or try specifying the IP address directly.

For any active systems on your network, you can see the details regarding the installed certificate on the right-hand pane of the dialog box. If the server you have highlighted does not have a certificate installed, the right pane is grayed out.

To create a new key, right-click the server you want to work with and select Create Key Request, or select Key, Create New Key from the menus. When you do, you see a dialog box that enables you to create the keyfile to send to the certificate authority you're going to use. Figure 10.4 shows this dialog box containing some example information.

Fig. 10.4 - Fill in all information about your organization as needed. Remember, the more information you provide, the more unique the key request will be.

There are a number of properties that you'll need to specify to create the key request. Table 10.1 shows the different parameters and what each of them means in the context of the certificate request.

Table 10.1 Key Manager Parameters
Key Name This is the "friendly name" of the key, and it's used to generate the default file name for the key, shown at the bottom of the dialog box in the Request File text box. In previous utilities, this was referred to as the private_key parameter.

Password This is the password that you're creating the key with. This password is critical to the process of creating the key, so be sure to write it down.

Bits You can create a key of three different sizes, each of which indicates a different level of security. As the size of the key goes up, the security of the channel increases as well. The options are 512, 768, 1024. The default is a 1024-bit key.

Request The name and location of the file that will contain the certificate request. You will send this file to the certificate authority. An extension of .REQ is automatically added to the resulting file.

Distinguishing Information The next items are combined to create the distinguished name for your server-and subsequently, the certificate.

Organization The name of the company that will be running the server.

Organizational Unit The department that will be running the server. This helps distinguish the server from others that may be running within a large corporation.

Common Name The name that users will be using to access the system. For your Intranet-only server, this can be the computer name, such as HOLODECK3. For an Internet server, this should include both the system and domain names, such as www.intellicenter.com or www.integra.net, rather than just intellicenter or even integra.net. This was referred to as the CN parameter in previous versions of the key management utilities, indicating the net address of the system.

Country The name of the country in which the server will be based.

State/Province The State or Province in which the server will reside.

Locality Locality or town in which the server will reside.

Request File The name of the file in which you'll be storing the key information. This is very important to note, as you'll be sending this file to the certificate authority as part of this process.

Table 10.1 Key Manager Parameters
Key Name	This is the "friendly name" of the key, and it's used to generate the default file name for the key, shown at the bottom of the dialog box in the Request File text box. In previous utilities, this was referred to as the private_key parameter.
Password	This is the password that you're creating the key with. This password is critical to the process of creating the key, so be sure to write it down.
Bits	You can create a key of three different sizes, each of which indicates a different level of security. As the size of the key goes up, the security of the channel increases as well. The options are 512, 768, 1024. The default is a 1024-bit key.
Request	The name and location of the file that will contain the certificate request. You will send this file to the certificate authority. An extension of .REQ is automatically added to the resulting file.
Distinguishing Information	The next items are combined to create the distinguished name for your server-and subsequently, the certificate.
Organization	The name of the company that will be running the server.
Organizational Unit	The department that will be running the server. This helps distinguish the server from others that may be running within a large corporation.
Common Name	The name that users will be using to access the system. For your Intranet-only server, this can be the computer name, such as HOLODECK3. For an Internet server, this should include both the system and domain names, such as www.intellicenter.com or www.integra.net, rather than just intellicenter or even integra.net. This was referred to as the CN parameter in previous versions of the key management utilities, indicating the net address of the system.
Country	The name of the country in which the server will be based.
State/Province	The State or Province in which the server will reside.
Locality	Locality or town in which the server will reside.
Request File	The name of the file in which you'll be storing the key information. This is very important to note, as you'll be sending this file to the certificate authority as part of this process.

Be sure you spell out city and state names fully. This is a requirement from the Certifying Authority (CA) in most cases, and it serves to more fully qualify the certificate request. If you don't, your request may be bounced from the CA, adding unnecessary time to the process of obtaining your certificate.

The parameters you pass as the distinguished site name are all provided as a single string, enclosed in quotes. See the example below for more information.

Don't embed commas in the information you provide to create the distinguished name. For example, "Custom Solutions, Inc." would not be valid. This is because the comma is used to indicate the break between the different characteristics of the distinguished name. By placing a comma in the string, you're indicating that the field is completed and the parsing routine should move to the next field.

When you select OK, it prompts you to confirm the password you entered. Be sure to enter a password that exactly matches the original you provided. If you don't, Key Manager indicates that the passwords don't match and returns you to the Key Manager dialog box to confirm or change the password. Keep in mind that the password is case sensitive.

After you've successfully generated the key request, you'll receive a message indicating that you need to send the file to the certificate authority. The file you indicated for the Request File is created with the certificate request. Here is an example certificate request.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBrTCCARYCAQAwcDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldBU0hJTkdUT04x
EDAOBgNVBAcTB1JFRE1PTkQxEDAOBgNVBAoTB0VYQU1QTEUxDTALBgNVBAsTBFRP
VVIxGTAXBgNVBAMUEHd3dy5teWNvbXBhbnkuY28wgZ4wDQYJKoZIhvcNAQEBBQAD
gYwAMIGIAoGAeAku5DMBNnYZQI+cpitWsLGxMwf/mHl9t1flG05NoFrLJQcJKZbh
B9jAAWDCau7kD+usYd0C0tyTyhMkhg76/5Mqr8itZEhSF61OCb5+719abTy0sX7x
iuJuDhkeQl6eW3+r7al4XSp2roF6xhu2VwgPNJjpfTpjHztGo55hwRsCAwEAATAN
BgkqhkiG9w0BAQQFAAOBgQBbaQuqjvYYZ1hWG+giDKz9DrpAsu+PJpihAFeTjw/+
wGYVu4HUvIOdKJpGPs9VOxRzEZesk1uMkz+qmCixLsSkrnt2T8O7nnClrYKGcJdl
d/nz1rol7HlXNS+kl6YezoHEquoWyi7qFW+El4UEksiElKpscSdWxgKgHuwqsKBp
kg==
-----END NEW CERTIFICATE REQUEST-----

If you look at the certificate request file listing, MyKEY file, you'll quickly see that it appears to be just a jumble of characters. The file contains an encrypted form of the request information you provided in the dialog box. Once you have requested the certificate, it appears in the Key Manager with the pending status indicated in the right pane. See Figure 10.5 for an example of what this dialog box now looks like.

Fig. 10.5 - You can quickly see the status of all servers and their keys from the Key Manager.

You send this information to the certificate authority for signing, and they use it as the basis for the key they will issue you. In these examples, I am using VeriSign, but others are in discussion with the various Web server vendors and will be in production reasonably soon.

Next, you send your request to the certificate authority for validation and for signing. Signing is the process of producing the complementary key to the certificate request you submit.

Sending in your request

When you send in your request to the certificate authority, they ask for a couple of things from you. First, you need to e-mail your certificate request file to the certificate authority, as this is the starting point for what they'll be creating for you.

With VeriSign, and others that I have reviewed, you must fax and mail a letter, on company letterhead, to the certificate authority. This letter takes responsibility for the key, indicates who the responsible Webmaster people are for the site, and tells the name you'll be using for the site.

VeriSign, Inc.
Attn: Digital ID Services
2593 Coast Avenue,
Mountain View, CA 94043
USA

Our Server Name (also referred to as Common Name) is "<your server name>."

I, <person signing this letter>, hereby attest that the following individuals are employees of <company>. I further attest that they are authorized to operate the software referred to as the Microsoft Internet Information Server.

I understand that use of the Digital ID requested by this letter is subject to the terms of the Secure Server Legal Agreement. That document can be found at http://www.verisign.com/microsoft/legal.html. The secure Server Legal Agreement is also available upon request from VeriSign at 2593 Coast Avenue, Mountain View, CA 94043.

<company> hereby certifies to VeriSign, Inc. that it has the right to use the name presented in the Organization field within the Server Name. The proof of right to use the name is based on registering the respective organization name with the state, country, or city in which the Microsoft Internet Information Server will be operated.

When you send in your request, you should include the older version command line equivalent for the certificate request. As of this writing, this was a requirement, as Verisign uses it to validate the key request that you send in. To do this, with your key request message, include the following information:
KEY REQUEST COMMAND LINE:

keygen [password] Key Request "C=US, O=Joe's Barber Shop, S=Washington, L=Redmond, CN=barber.com"
You can determine the information for this command line from the Key Manager display, and from using the information presented in Table 10.1. These two lines provide any additional information needed to complete your key request.

Once you've submitted the information, you must wait for the signed certificate to be e-mailed back to you. When you receive it, save the key to a text file on your system. Listing 10.1 shows a partial certificate example.

Listing 10.1 : Partial certificate listing

-----BEGIN CERTIFICATE-----
MIICWjCCAccCBQJ6AAjLMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UECxMlU2VjdXJl
...
...
fKhP4wfgwI4w59ubZ3xuDnzvULxk7H4wu/A/36GtC6B4weyNqmhCUB29xbWVP29w
178esPfem//YpkBy1jLly+ynA82iGN0gu2UCAwEAATANBgkqhkiG9w0BAQIFAAN+
ADhQaghTBWWOkc4IzYEoOriKmJGXRsDcTHfGwAZ52nelXhaVVtQQxQhQqXjSmcSE
4sfuesfZTsZTlbhEscG27cVH2ktY7CRcO3C7BMFBvNqEdLPPCXyZdiqZBCprsROU
xAfjPTSXXMYa1/2ccBRbPS58n75nlEAugbOfHFAn
-----END CERTIFICATE-----

When you receive and save the certificate information, be sure you save it with the "BEGIN CERTIFICATE" and "END CERTIFICATE" monikers in place. This indicates to the key manager where the certificate starts and stops. At this point, you're ready to install the certificate and begin applying it to your system's directories.

Installing Digital Certificates On Your Server

The certificate you receive will look similar to the one shown above. Once again, the text block has no obvious meaning and it appears to be a set of jumbled characters. Rest assured, this certificate information provides quite a lot of information about your site, indicating everything from your distinguished name to the expiration date of the certificate.

Certificates generally expire one year after their issue. The cost for renewing a certificate is typically much less than the cost of registering a new name, often less than 1/2 of the fee required to initially set up your system's address on the Internet. In addition, the application process should be much reduced, often not requiring much more than simply paying the renewal fee.

Next, use the Key Manager utility, also located on the Internet Server menu option from your Start menu, to register the certificate. There are a number of different ways to apply a certificate to your site. Your approach will vary according to what type of security you're trying to provide on the site.

The Key Manager application has a number of capabilities, only the first of which is ability to set up certificates for your server that apply to the server as a whole. Other capabilities include setting up the certificate for use on multi-homed or Virtual Servers.

Installing the Certificate on Your System

Once you receive your certificate, you need to install and validate it for your system. The Key Manager lists any "open" or yet-to-be-validated keys when you start the application. These keys appear with a red line through the key name. See Figure 10.6 for an example.

Fig. 10.6 - Keys that have been requested but not yet validated for use on your server are shown with the "No Key" icon.

To install the certificate, right-click on the key request you used to create the request for the certificate. From the menu, select Install Certificate. You'll need to select the file into which you saved the validated certificate so that you can apply it to the site. After you do, it prompts you for the password that you used to create the original key request. See Figure 10.7.

Fig 10.7 - You must provide the same password that you used to request the certificate when you started the process of certifying your server.

After you provide the password, it reminds you that, until you apply the certificate to a specific server, the certificate is valid but not in use. As you can see in Figure 10.8, the default application of the certificate when you initially install it is "None," indicating that it is installed but not applied to any content or directories.

Fig. 10.8 - You must apply a certificate to a server in order to activate it on your site.

When you apply your certificate, you'll need to first determine your goals for its use on the site. If you are planning to provide the certificate against all transactions for this server, you'll be able to use the Default option, applying the certificate system-wide against your site. There may also be cases where you will have a different certificate for different IP addresses serviced by this server. In those cases, you'll need to take a slightly different approach. The next sections show how you can apply the certificate in these scenarios to get the most out of your site.

Installing the Certificate on a Single Server System

If you'll be using the same certificate for all requests on a given server, you can make the same certificate available to all directories and virtual directories by selecting the Default option in the Server Connection frame in the Key Manager dialog box. This option simply indicates that, if there are multiple virtual or multi-homed servers installed on this system, they are going to be all using the same certificate. Figure 10.9 shows that you can also tell, by the Key Manager server display, that the key is the default key for all activity designated as secure for that server.

Fig. 10.9 - The Key Manager indicates whether an installed certificate is for a specific virtual server or general application for the server.

This sets up the certificate in such a manner that, when you create an SSL-protected directory, it automatically uses this certificate. Keep in mind that just because you relate a certificate with a server, you don't have to protect every directory provided by that server. It simply means that the SSL capabilities are available when you need them.

Installing the Certificate on a Multi-Home or Virtual Server System

If you have a virtual server environment, you may wish to install separate certificates for each virtual server you are hosting. You can associate a given certificate with a specific IP address, or you can use a certificate for all virtual servers supported by the server.

There are restrictions on how you can use the certificate and what types of multi-server support you can apply it to. You should carefully read your Certificate Authority's Use and Guidelines documents for more information about whether you can use a common certificate in a multi-homed server environment.
If you're setting up virtual servers to serve the same content, as might be the case when you've established an Intranet and Internet presence on a single machine, you can probably use the certificate for both server sessions.
On the other hand, if you have a virtual server set up and each virtual server represents a different company name, URL, or common name (e.g. www.integra.net), or is otherwise related to a different line of business, you should apply for separate and distinct certificates. There are usually discounts for single businesses purchasing multiple certificate licenses, so this should save some of the upfront costs associated with these scenarios.

To select a specific virtual server, select the IP Address option in the Server Connection frame and provide the IP address for the server you want to add the certificate against. Once you provide the address, the Key Manager updates the left-hand pane to show the IP address associated with the certificate. See Figure 10.10 for an example.

Fig. 10.10 - When you assign a specific IP address to a given certificate, the Key Manager shows the IP next to the certificate under the server heading.

Once installed, the certificate is available only for the server you called out. You must get a separate certificate for the balance of your site if there are other virtual servers and the need arises.

If you later change your mind and decide that you want to provide the certificate capabilities on a more site-wide basis, you can uninstall the certificate and then reinstall it with the Default option selected. You can also select the certificate and change its association with the Server Connection by simply selecting a different radio button from the dialog box.
If you do end up doing a reassignment of this type, you'll need to set up your protected directories again, verifying that SSL remains enabled.

Removing Installed Certificates

You may wish to uninstall a certificate for a number of reasons. For example, if you've had your certificate on the system and have determined that you no longer need to provide the secure content, you may wish to remove the certificate.

There is a certain amount of overhead associated with providing a secure connection. As you might imagine, encrypting and decrypting information on both ends of the link to your site can have a noticeable impact on performance.
If you have content that does not need to be under SSL protection, you should consider removing the SSL encryption

To remove an installed certificate, right-click on the certificate entry under the server heading you need. Select Delete from the menu. When you do, it asks you to verify that you want to remove the certificate. See Figure 10.11.

Changes that you make to the keys and certificates on your system are not actually applied until you commit the changes to your system. You commit changes by selecting either Servers, Commit Changes Now from the menus, or by exiting the Key Manager and indicating that you want the changes saved when prompted.

Fig. 10.11 - When you remove a certificate, you also remove the protection from the SSL-enabled directories. It prompts you to confirm that you want to remove the SSL certificate from your system.

When you have confirmed the removal of the certificate, the certificate reference disappears from the dialog box. You can reinstall the certificate if needed, but you'll need to give the same information you used to generate the original, including the password and other items that are required to create the distinguished name for your system. If you don't, the certificate installation fails.

Applying the Certificate to Your Directories

When you install the certificate through the Key Manager, it is applied only to the server. It's not applied to any content or directories on your system. You need to specify the directories that contain content that you need to provide through the secure medium.

There's an important distinction between providing a secure transaction such as this and securing your Web site. SSL and the certification process provides for a private "channel" between a Web browser-type environment and your site, ensuring that no unauthorized person can steal information from the connection.
SSL does not provide protection against unwanted intruders. You'll notice that, as you use SSL-protected directories, you're not authenticated at all. This is because it sets up a secure session between the browser and your server. The server does not care who the user is, only that the information sent to the user arrives intact and that no other people are able to intercept and understand the packets of information being transferred.
If you're concerned about site security, refer to Chapter 9, where we cover Firewalls and other types of security.

Next, you apply the certificate to your Web site. To do so, start the Internet Service Manager and select the WWW service. From the property sheets, select the Directories tab. You apply a certificate on a directory-by-directory basis, enabling you to provide both secure and non-secure content to your users.

When you assign a directory to be secure, be sure that no parent directory is unsecured. In other words, if you have a directory structure where SUBDIR1 is inside MAIN, don't provide an unsecured access point to MAIN and then secure SUBDIR1. Someone coming in from the MAIN directory has full, unsecured access to the SUBDIR1 area. This is because they are not coming in through a directory that provides the SSL encryption.

When you install a certificate against a given server, you should stop and restart the WWW service to make sure it sees the newly installed certificate. If you don't, the SSL option may not be available when you go to associate it with a directory.

Figure 10.12 shows an example of the dialog box that lets you indicate the SSL flag on a directory.

Fig. 10.12 - When you edit an existing virtual directory, or when you create a new virtual directory, you can specify that it should be used with the SSL encryption.

Once you set the SSL flag, all accesses that use that directory require the use of SSL.

When you set up a site, consider whether you want to force people to use SSL or only provide it as an option. If as an option, you can provide one virtual directory to the secure content and another one that isn't. Then, based on the user selection when they're browsing your server, you can take them to the secure or non-secure pages. The physical files remain the same because you can create two virtual directories to reference the same physical location on your system. The links you provide your users make the distinction between protected and unprotected content merely by selecting an appropriate hyperlink from your site.

Establishing a Secure Session

Now that you've installed the certificate, how do you modify your installation to provide secure content? The biggest difference you'll see as system administrator is the use of a slightly different URL to access pages that are secure.

You may recall from the beginning of this book that there are several different types of URLs, ranging from HTTP: to NEWS:. This is how the browser knows what type of protocol to use to access the site. In the case of an SSL site, you'll use yet another variation the URL. When you see a reference to a site with an HTTPS: URL, you know that it's using data encryption, and so does your browser. When a user visits the site, the secure connection is automatically set up.

In the previous section, I mentioned that you can provide both secure and unsecured links to the same content on disk. For an example of this, consider the following scenario:

You have set up two directories, "s_content" for secure content and "content" for unsecured content.
Both virtual directories point to the same directory on your hard disk.
The content you're providing is an order form.
Some of your users are concerned about secure transactions, and others aren't.

You can offer links on your pages as follows:

...
<a href="http://www.mysite.com/s_content/default">
Secure transaction pages...</a>
<a href="https://www.mysite.com/content/default">
Unsecure transaction pages...</a>
...

Since you've pointed both URLs to the same content, the user can decide how to access the content on your site. This is a good way to provide access to order forms and other information where it may be desirable to have secured access but it should not be required. In cases where you want to strictly enforce the use of the secure channel, you can simply not provide the non-HTTPS: URL.

When a user accesses the content on an HTTPS: URL, the balance of the conversation between the Web site and the browser remains secure until the user accesses a different, non-HTTPS URL.

Reality Check

At the Reality Check sites, the SSL capabilities are very important. At the Integra site, the SSL approach secures transactions to enable the real-time purchase and download of software from the site. By using SSL, you can retrieve credit card and other payment information without worrying about giving that information to persons who have no business with it.

The Integra site features download options for retail builds of software, downloads of evaluation copies, and more. The SSL enables you to provide these items directly to the user without the requiring any other correspondence or calls to the user to get payment information before the download.

At the IntelliCenter Reality Check site, SSL not only receives orders and payments for classes, but also protects "transcripts" for students. The transcripts give students information on what classes they've attended to date, so it's important that the information be transferred correctly. IntelliCenter also uses to the SSL encryption for transferring company-sensitive information when accessing company databases for maintenance, reporting, and other purposes. This enables users to retrieve critical company information like marketing information, financial information, and other items, all over the Internet and without a worry about having the information become corrupted or fall into the wrong hands.

From Here...

SSL can bring a good level of protection to your site-a level of protection that enables you to confidently allow even financial transactions on your site. You should consider the following additional sources of information for related topics:

Chapter 2, "Installing and Understanding Windows NT Server," gives you insight into the workings of the NT Server security subsystem and controlling access to your server in that regard.
Chapter 9, "Security Issues--Firewalls and Data Security," covers providing Firewall access to and from your Intranet to the Internet. While SSL encrypts information, it does not provide access controls to the information you are hosting.
Que's Special Edition Using Windows NT Server by Roger Jennings goes into great detail on the inner workings of the NT security system and how you can use it to control access to your server from an Intranet perspective.

Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103^rd Street, Indianapolis, IN 46290.
Notice: This material is from BackOffice Intranet Kit, ISBN: 0-7897-0848-5. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.