CHAPTER 5

Securing Your Site Against Intruders

How Internet Information Server Security Works
Controlling Anonymous Access
Controlling Access by User or Group
Setting Folder and File Permissions
Setting WWW Directory Access
Controlling Access by IP Address
Running Other Network Services
Securing Data Transmissions with Secure Sockets Layer (SSL)

Whether your Web server is handling millions of accesses directly over the Internet or maintaining departmental documents on your intranet, security is an important consideration. When you connect computers to an intranet or an Internet, you can communicate with people and computers worldwide. This broad flexibility imposes a degree of risk — not only can you communicate with people on other networks, users on other networks can initiate communication with your network. Although connecting to Web servers is generally done with good intentions, there are malicious individuals who attempt to infiltrate internal networks.

The Windows NT operating system was designed to help you secure your system against intruders. Internet Information Server builds on the Windows NT security model and provides additional monitoring and security features. This chapter will help you effectively use Windows NT security and Internet Information Server security at your site. You should understand all of the information in this chapter before connecting your computer to a public network. If you do not understand the information, you should consult Windows NT documentation, an authorized Microsoft Solution Provider, or other qualified source before installing your site on the Internet.

This chapter explains:

- How Internet Information Server security works.

- Controlling anonymous access to your Web site.

- Controlling access by user name or group name.

- Requiring a user name and password for authenticated access.

- Controlling access by setting folder and file permissions.

- Securing data transmissions with SSL.

# How Internet Information Server Security Works

Internet Information Server is built on the Windows NT security model. Windows NT security helps you protect your computer and its resources by requiring assigned user accounts and passwords. You can control access to computer resources by limiting the user rights of these accounts. You can use the Windows NT File System (NTFS) to assign permissions to folders and files on your computer. You can control access to folders and files by preventing users from copying files to or from a folder, or by preventing users from executing files in certain folders.

In addition to the Windows NT security features, you can set Read-only or Execute-only virtual directories by using Internet Service Manager. Internet Information Server also provides a way to deny user access to computers with particular IP addresses. IIS supports the Secure Sockets Layer (SSL) protocol, which securely encrypts data transmissions between clients and servers.

When an IIS Web server receives a browser request for information, it determines whether the request is valid. A simple overview of the security process used on each request is presented in the following illustration.

The following sections explain how to configure Windows NT and the Internet services to protect your system.

# Controlling Anonymous Access

On many Web servers, almost all WWW, FTP, and gopher access is anonymous; that is, the client request does not contain a user name and password. This occurs in the following cases:

- An FTP client logs on with the user name “anonymous.”

- All gopher requests.

- A Web browser request does not contain a user name and password in the HTTP header (this is the default on new Web connections with most browsers).

Even though the user is not logged on with an individual user name and password, you can still control and monitor anonymous access. Each Internet service maintains a Windows NT user name and password that is used to process anonymous requests. When an anonymous request is received, the service “impersonates” the user configured as the “anonymous logon” user. The request succeeds if the anonymous logon user has permission to access the requested resource, as determined by the resource’s Access Control List (ACL). If the anonymous logon user does not have permission, the request fails. You can configure the WWW service to respond to a failed anonymous request by requiring the user to provide a valid Windows NT user name and password, a process called authentication.

## Configuring the Anonymous User Account

You can view and monitor the anonymous logon user account on the Service property sheets of Internet Service Manager (for the WWW, FTP, and gopher services). Each service running on the same computer can use either the same or different anonymous logon user accounts. Including the anonymous logon user account in file or folder ACLs enables you to precisely control the resources available to anonymous clients.

The anonymous logon user account must be a valid Windows NT user account on the server providing the Web services, and the password must match the password for this user in that computer’s user database. User accounts and passwords are configured in the Windows NT User Manager by setting User Rights in the Policies menu. The anonymous logon user account must have the Log on Locally user right.

The IUSR_computername account is automatically created (with a randomly generated password) during Internet Information Server setup. For example, if the computer name is marketing1, then the anonymous access account name is IUSR_marketing1.

By default, all Web client requests use this account. In other words, Web clients are logged on to the computer by using the IUSR_computername account. The IUSR_computername account is permitted only to log on locally on the server providing the Web services.

Note The IUSR_computername account is also added to the group Guests. If you have changed the settings for the Guests group, those changes also apply to the IUSR_computername account. You should review the settings for the Guests group to ensure that they are appropriate for the IUSR_computername account.

For the WWW and FTP services, you can allow or prevent anonymous access (all gopher requests are anonymous). For each of the Web services (WWW, FTP, and gopher), you can change the user account used for anonymous requests and change the password for that account.

#### To allow anonymous access

1. In Internet Service Manager, double-click the WWW service or the FTP service to display its property sheets, then click the Service tab.

2. For the WWW service, select the Allow Anonymous check box. For the FTP service, select the Allow Anonymous Connections check box.

3. Click OK.

#### To change the account or password used for anonymous access

1. In Internet Service Manager, double-click the service to display its property sheets, then click the Service tab.

2. In the Anonymous Logon user name box, type the new user name.

The default user account is IUSR_computername, where computername is the name of your server. This account is created automatically when you set up Internet Information Server.

3. In the Password box, type the new password.

A randomly generated password is automatically created for the IUSR_computername account.

Note If you change the password for this account, you must also specify the new password for the account in User Manager.

4. Click OK.

## Using the Anonymous Account on Domain Controllers

When Internet Information Server is installed on a primary or secondary domain controller, the anonymous logon user account is created in the user account database of the domain. When Internet Information Server is installed on a domain member-server, or a stand-alone server, the account is created on the local computer.

If Internet Information Server is installed on multiple domain controllers of the same domain, a separate user account is created in the domain user database for each Internet server computer. This does not cause any conflicts because each user name is unique, containing the name of the associated computer. However, you may find it more convenient to create a single anonymous logon user account in the domain to use for all Internet Information Server domain controllers in the domain. This can simplify administration of ACLs. To do this, follow these steps:

- In User Manager for Domains, create a new anonymous logon user account in the domain. Be sure that this account is made a member of appropriate groups, given a secure password, and is given the User Right (in the Policies menu) to log on locally.

- On the Service property sheet of Internet Service Manager, specify the new anonymous logon user name and password. You must do this for each Internet Information Server service running on all primary and secondary domain controllers in the domain.

- When later installing Internet Information Server on other domain controllers in the domain, be sure to use Internet Service Manager to modify the anonymous logon user name and password to match those created with User Manager for Domains. Do this for each Internet Information Server service installed.

If you allow remote access only by the IUSR_computername account, remote users do not provide a user name and password, and have only the permissions assigned to that account. This prevents hackers from attempting to gain access to sensitive information with fraudulent or illegally obtained passwords. For some situations this provides the best security.

# Controlling Access by User or Group

You can control access to your Web site by using the Windows NT User Manager to specify what certain users or groups of users are allowed to do on your server. You can further control access by requiring Web client requests to provide a user name and password that Internet Information Server confirms before completing the request.

## Setting Up User Accounts

Windows NT security helps you protect your computer and its resources by requiring assigned user accounts. Every operation on a computer running Windows NT identifies who is doing the operation. For example, the user name and password that you use to log on to Windows NT identifies who you are and defines what you are authorized to do on that computer.

What a user is authorized to do on a computer is configured in User Manager by setting user rights in the Policies menu. User rights authorize a user to perform certain actions on the system, including the Log on Locally right, which is required for users to use Internet services if Basic authentication is being used.

If you are using Windows NT Challenge/Response Authentication, then the Access this computer from network right is required for users to use Internet services. By default, everyone has this right.

To increase security, follow these guidelines:

- Do not give the IUSR_computername account, the Guests group, or the Everyone group any right other than the Log on Locally or the Access the computer from this network right.

- Make sure that all user accounts on the system, especially those with administrative rights, have difficult-to-guess passwords. In particular, select a good administrator password (a long, mixed-case, alphanumeric password is best) and set the appropriate account policies. Passwords can be set by using User Manager, or by typing at the system logon prompt.

- Make sure that you specify how quickly account passwords expire (which forces users to regularly change passwords), and set other policies such as how many bad logon attempts will be tolerated before locking a user out. Use these policies to prevent exhaustive or random password attacks, especially on accounts with administrative access. You can set these policies by using User Manager.

- Limit the membership of the Administrator group to trusted individuals.

- If you use the predefined Windows NT user accounts INTERACTIVE and NETWORK for access control, make sure files in your Web site are accessible to these user accounts. In order for a file to be accessed by anonymous client requests or client requests using Basic authentication, the requested file must be accessible by the INTERACTIVE user. In order for a file to be accessible by a client request that uses Windows NT Challenge/Response authentication protocol, the file must be accessible by the NETWORK user.

## Requiring a User Name and Password

You can restrict Web site access to only authenticated clients; that is, Web clients that supply a valid Windows NT user name and password. When you use authentication, no access is permitted unless a valid user name and password are supplied. Password authentication is useful if you want only authorized individuals to access your Web site or specific portions controlled by NTFS. You can have both anonymous logon access and authenticated access enabled at the same time.

The WWW service provides two forms of authentication: basic and Windows NT Challenge/Response (sometimes referred to as “NTLM”).

Basic authentication does not encrypt transmissions between the client and server. Because Basic authentication sends the client’s Windows NT user name and password in essentially unencrypted over the networks, intruders could easily learn user names and passwords.

Windows NT Challenge/Response authentication, currently supported only by Microsoft Internet Explorer version 2.0 or later, protects the password, providing for secure logon over the network. In Windows NT Challenge/Response authentication, the user account obtained from the client is that with which the user is logged on to the client computer. Because this account, including its Windows NT domain, must be a valid account on the Windows NT-based server running Internet Information Server, Windows NT Challenge/Response authentication is very useful in an intranet environment, where the client and server computers are in the same, or trusted, domains. Because of the increased security, Microsoft recommends using the Windows NT Challenge/Response method of password authentication whenever possible.

You have both Basic and Windows NT Challenge/Response authentication enabled by default. If the browser supports Windows NT Challenge/Response, it uses that authentication method. Otherwise, it uses Basic authentication. Windows NT Challenge/Response authentication is currently supported only by Internet Explorer 2.0 or later.

You can require client authentication for all FTP service requests or only for anonymous requests that fail. The FTP service supports only Basic authentication; therefore, your site is more secure if you allow anonymous connections. Your site is most secure if you allow only anonymous FTP connections.

#### To enable authentication for the WWW service

1. In Internet Service Manager, double-click the WWW service to display its property sheets, then click the Service tab.

2. Select Basic (Clear Text), Windows NT Challenge/Response, or both.

3. Click OK.

#### To enable authentication for the FTP service

1. In Internet Service Manager, double-click the FTP service to display its property sheets, then click the Service tab.

2. To enable authentication for failed anonymous connections, clear (delete) the Allow only anonymous connections check box.

3. To require all client requests to be authenticated, clear the Allow Anonymous Connections check box.

Warning FTP and WWW Basic authentication send passwords across the network in clear text (that is, unencrypted), as does HTTP Basic authentication.

## How Anonymous Logons and Client Authentication Interact

You can enable both anonymous connections and client authentication for the WWW service and for the FTP service. This section explains how an IIS Web server responds to these access methods when both are enabled.

Note that if client authentication is disallowed and anonymous connections are allowed, a client request that contains a user name and password is processed as an anonymous connection, and the server ignores the user name and password.

### WWW Service

When the WWW service receives a client request that contains credentials (a user name and password), the “anonymous logon” user account is not used in processing the request. Instead, the user name and password received by the client are used by the service. If the service is not granted permission to access the requested resource while using the specified user name and password, the request fails, and an error notification is returned to the client.

When an anonymous request fails because the “anonymous logon” user account does not have permission to access the desired resource, the response to the client indicates which authentication schemes the WWW service supports. If the response indicates to the client that the service is configured to support HTTP Basic authentication, most Web browsers will display a user name and password dialog box, and reissue the anonymous request as a request with credentials, including the user name and password entered by the user.

If a Web browser supports Windows NT Challenge/Response authentication protocol, and the WWW service is configured to support this protocol, an anonymous WWW request that fails due to inadequate permissions will result in automatic use of the Windows NT Challenge/Response authentication protocol. The browser will then send a user name and encrypted password from the client to the service. The client request is reprocessed, using the client’s user information.

If the WWW service is configured to support both Basic and Windows NT Challenge/Response, the Web server returns both authentication methods in a header to the Web browser. The Web browser then chooses which authentication method to use. Because the Windows NT Challenge/Response protocol is listed first in the header, a browser that supports the Windows NT Challenge/Response protocol will use it. A browser that does not support the Windows NT Challenge/Response protocol will use Basic authentication. Currently, Windows NT Challenge/Response authentication is supported only by Internet Explorer 2.0 or later.

### FTP Service

When the FTP service receives a client request that contains credentials (a user name and password), the “anonymous logon” user account is not used in processing the request. Instead, the user name and password received by the client are used by the service. If the service is not granted permission to access the requested resource while using the specified user name and password, the request fails, and an error notification is returned to the client.

When an anonymous request fails because the “anonymous logon” user account does not have permission to access the desired resource, the server responds with an error message. Most Web browsers will display a user name and password dialog box, and reissue the anonymous request as a request with credentials, including the user name and password entered by the user.

Warning Because the FTP service (and WWW Basic authentication) sends user names and passwords unencrypted over the network, intruders could use protocol analyzers to read the user names and passwords.

## Creating Customized Authentication Schemes

If you need a WWW request authentication scheme not supported by the service directly, obtain a copy of the Win32 Software Development Kit (SDK), and read the ISAPI Filters specification on how to develop user-written ISAPI Filter dynamic-link libraries (DLLs) that handle request authentication. The Win32 SDK is available through the Microsoft Developer Network. For more information, visit the Microsoft home page (http://www.microsoft.com).

# Setting Folder and File Permissions

Every access to a resource, such as a file, an HTML page, or an Internet Server API (ISAPI) application, is done by the services on behalf of a Windows NT user. The service uses that user’s user name and password in the attempt to read or execute the resource for the client. You can control access to files and folders in two ways:

- By setting access permissions in the Windows NT File System (NTFS)

- By setting access permissions in the Internet Service Manager

Note File Allocation Table (FAT) file system partitions do not support access control. However, an FAT partition may be converted to NTFS by using the convert utility. Refer to Windows NT documentation for more information on using this utility.

## Setting NTFS Permissions

You should place your data files on an NTFS partition. NTFS provides security and access control for your data files. You can limit access to portions of your file system for specific users and services by using NTFS. In particular, it is a good idea to apply Access Control Lists (ACLs) to your data files for any Internet publishing service.

ACLs grant or deny access to the associated file or folder by specific Windows NT user accounts, or groups of users. When an Internet service attempts to read or execute a file on behalf of a client request, the user account offered by the service must have permission, as determined by the ACL associated with the file, to read or execute the file, as appropriate. If the user account does not have permission to access the file, the request fails, and a response is returned, informing the client that access has been denied.

File and folder ACLs are configured by using the Windows NT Explorer. The NTFS file system gives you very fine control on files by specifying users and groups that are permitted access and what type of access they may have for specific files and directories. For example, some users may have Read-only access, while others may have Read, Change, and Write access. You should ensure that the IUSR_computername or authenticated accounts are granted or denied appropriate access to specific resources.

You should note that the group “Everyone” contains all users and groups, including the IUSR_computername account and the Guests group. By default the group Everyone has full control of all files created on an NTFS drive.

If there are conflicts between your NTFS settings and Microsoft Internet Information Server settings, the strictest settings will be used.

You should review the security settings for all folders in your Web site and adjust them appropriately. Generally you should use the settings in the following table:

Directory Type | Suggested NTFS Access
content | Read access
programs | Read and Execute access
databases | Read and Write access

#### To secure your files on an NTFS drive

1. Put your files on your NTFS drive and add them to your Web site by using the Directories property sheet in Internet Service Manager.

2. In Windows NT Explorer, right-click the folder (directory) you want to secure (select your site root to secure the entire site), and choose Properties.

3. In the Properties dialog box, choose the Security tab.

4. In the Security dialog box, choose Permissions.

5. In the Directory Permissions dialog box, click Add to add users and groups.

6. In the Add Users and Groups dialog box, add the users that should have access.

7. Click OK.

8. In the Directory Permissions dialog box, select the users and groups that should have permissions.

9. From the Type of Access list box, choose the permission level you want for the selected user or group.

10. Click OK.

## Auditing File Access

To determine whether anyone has gained unauthorized access to sensitive files, you can audit the access of NTFS files and folders. For example, you can check for attempts by members of a specific user group to read files. You should review the audit records periodically to check for unauthorized access. To set auditing on a file or folder, use User Manager for Domains to enable auditing of File and Object Access, and then use Windows NT Explorer to specify which files to audit and which types of file access events to audit. To review audit entries, use Event Viewer.

For more information on setting the audit policy for files and folders, see the Windows NT documentation.

# Setting WWW Directory Access

When creating a Web publishing directory (folder) in Internet Service Manager, you can set access permissions for the defined home directory or virtual directory, and all of the folders in it. These permissions are those provided by the WWW service and are in addition to any provided by the NTFS file system. The permissions are:

Read Read permission enables Web clients to read or download files stored in a home directory or a virtual directory. If a client sends a request for a file that is in a directory without Read permission, the Web server returns an error. Generally, you should give directories containing information to publish (HTML files, for example) Read permission. You should disable Read permission for directories containing Common Gateway Interface (CGI) applications and Internet Server Application Program Interface (ISAPI) DLLs to prevent clients from downloading the application files.

Execute Execute permission enables a Web client to run programs and scripts stored in a home directory or a virtual directory. If a client sends a request to run a program or a script in a folder that does not have Execute permission, the Web server returns an error. For security purposes, do not give content folders Execute permission.

A client request can invoke a CGI application or an Internet Server Application Program Interface (ISAPI) application in one of two ways:

- The file name of the CGI executable or the ISAPI DLL can be specified in the request (URL). An example URL would be:

http://inetsrvr.microsoft.com/scripts/httpodbc.dll/scripts/pubs.idc?lname=Smith

For this request to be valid, the file Httpodbc.dll must be stored somewhere in the Web “publishing tree” (the directory structure that contains your content files; in this example, in the Scripts folder), and the folder it is stored in must have the Execute permission selected. This way the administrator can permit applications (CGI or ISAPI) to be run from a small number of carefully monitored directories.

- The other way to configure CGI and ISAPI applications is to use the Web File Extension Mapping feature, which allows your executables and DLLs to be stored somewhere other than the Web publishing tree. An example URL would be:

http://inetsrvr.microsoft.com/scripts/pubs.idc?lname=Smith

In this example, the script file (Pubs.idc) is stored in a folder of the Web publishing tree that has the Execute permission enabled. The service, upon receiving the request, will use the file-name extension mappings to determine where to find the application, which can be stored anywhere. This technique prevents users from invoking CGI and ISAPI applications directly by adding parameters in the URL. This is therefore a more secure mechanism, and useful for all Web applications and scripts. See “Associating Interpreters with Applications (Script Mapping)” in Chapter 10, “Configuring Registry Entries,” for more information.

#### To set access permissions for a directory

1. In Internet Service Manager, double-click the WWW service to display its property sheets, then click the Directories tab.

2. Select the folder for which you want to set permissions.

3. Click Edit Properties.

4. To allow Web clients to read and download the contents of a folder, select the Read check box.

5. To allow Web clients to run programs and scripts in a folder, select the Execute check box.

6. Click OK, then click OK again.

Note We recommend you set either Execute access or Read access on a folder, but not both. Executable scripts and programs should be kept in a virtual root separate from static Web content.

# Controlling Access by IP Address

Microsoft Internet Information Server can be configured to grant or deny access to specific IP addresses. For example, you can exclude a harassing individual by denying access to your server from a particular IP address, or prevent entire networks from accessing your server. Conversely, you can choose to allow only specific sites to have access to your service. IP address security is probably most useful on the Internet to exclude everyone except known users.

The source IP address of every packet received is checked against the Internet Information Server settings in the Advanced property sheet. If Internet Information Server is configured to allow access by all computers except those listed as exceptions to that rule, access is denied to any computer with an IP address included in that list. Conversely, if Internet Information Server is configured to deny all IP addresses, access is denied to all remote users except those whose IP addresses have been specifically granted access.

#### To deny access to a specific computer or group of computers

1. In the Advanced property sheet of Internet Service Manager, choose the Granted Access button.

2. Click Add.

3. In the IP Address box, type the IP address of the computer to be denied access to your site or click the button next to the IP Address box to use a DNS name, such as www.company.com.

To deny access to a group of computers, select Group of Computers. In the IP Address and Subnet Mask boxes, type the IP address and the subnet mask for a group to be denied access.

4. Click OK.

Access will be granted to all computers except the ones in the window with an Access status of Denied.

5. In the Advanced property sheet, click OK.

#### To grant access to only a specific computer or group of computers

1. In the Advanced property sheet of the Internet Service Manager, choose the Denied Access button.

This step denies access to all computers except those you specifically grant access to.

2. Click Add.

3. In the IP Address box, type the IP address of the computer to be granted access, or click the button next to the IP Address box to use a DNS name, such as www.company.com.

To grant access to a specific group of computers, select Group of Computers. In the IP Address and Subnet Mask boxes, type the IP address and the subnet mask for the group to be granted access.

4. Click OK.

Access will be denied to all computers except those in the window with an Access status of Granted.

5. In the Advanced property sheet, click OK.

# Running Other Network Services

You should review all of the network services that you are using on any computer connected to the Internet.

## Run Only the Services that You Need

The fewer services you are running on your system, the less likely a mistake will be made in administration that could be exploited. Use the Services application in Control Panel to disable any services not absolutely necessary on your Internet server.

## Unbind Unnecessary Services from Your Internet Adapter Cards

Use the Bindings feature in the Network application in Control Panel to unbind any unnecessary services from any network adapter cards connected to the Internet. For example, you might use the Server service to copy new images and documents from computers in your internal network, but you might not want remote users to have direct access to the Server service from the Internet.

If you need to use the Server service on your private network, disable the Server service binding to any network adapter cards connected to the Internet. You can use the Windows NT Server service over the Internet; however, you should fully understand the security implications and comply with Windows NT Server Licensing requirements issues.

When you are using the Windows NT Server service you are using Microsoft networking (the server message block [SMB] protocol rather than the HTTP protocol) and all Windows NT Server Licensing requirements still apply. HTTP connections do not apply to Windows NT Server licensing requirements.

## Check Permissions on Network Shares

If you are running the Server service on your Internet adapter cards, be sure to double-check the permissions set on the shares you have created on the system. You should also double-check the permissions set on the files contained in the shares’ folders to ensure that you have set them correctly.

## Do Not Enable Directory Browsing

Unless it is part of your strategy, you should not enable directory browsing on the Directories property sheet. Directory browsing potentially exposes the entire Web publishing file structure; if it is not configured correctly, you run the risk of exposing program files or other files to unauthorized access. If a default page (Default.htm) is not present and directory browsing is enabled, the WWW service will return a Web page containing a listing of files in the specified directory. It is always advisable to have a Default.htm page in any directory that you do not want to be browsed.

# Securing Data Transmissions with Secure Sockets Layer (SSL)

Previous sections of this chapter have dealt with securing your server from unauthorized access. This section discusses protocols that use cryptography to secure data transmissions to and from your server .

Microsoft Internet Information Server offers a protocol for providing data security layered between its service protocols (HTTP) and TCP/IP. This security protocol, called Secure Sockets Layer (SSL), provides data encryption, server authentication, and message integrity for a TCP/IP connection.

SSL is a protocol submitted to the W3C working group on security for consideration as a standard security approach for Web browsers and servers on the Internet. SSL provides a security “handshake” that is used to initiate the TCP/IP connection. This handshake results in the client and server agreeing on the level of security that they will use and fulfills any authentication requirements for the connection. Thereafter, SSL’s only role is to encrypt and decrypt the byte stream of the application protocol being used (for example, HTTP). This means that all the information in both the HTTP request and the HTTP response are fully encrypted, including the URL the client is requesting, any submitted form contents (such as credit card numbers), any HTTP access authorization information (user names and passwords), and all the data returned from the server to the client.

An SSL-enabled server can send and receive private communication across the Internet to SSL-enabled clients (browsers), such as Microsoft Internet Explorer version 2.0 or later.

SSL-encrypted transmissions are slower than unencrypted transmissions. To avoid reducing performance for your entire site, consider using SSL only for virtual folders that deal with highly sensitive information such as a form submission containing credit card information.

Enabling SSL security on a Web server requires the following steps:

1. Generate a key pair file and a request file.

2. Request a certificate from a certification authority.

3. Install the certificate on your server.

4. Activate SSL security on a WWW service folder.

Important Keep in mind the following points when enabling SSL security:

- You can enable SSL security on the root of your Web site (\InetPub\Wwwroot by default) or on one or more virtual folders.

- Once enabled and properly configured, only SSL-enabled clients will be able to communicate with the SSL-enabled WWW folders.

- URLs that point to documents on a SSL-enabled WWW folder must use “https://” instead of “http://” in the URL. Any links using “http://” in the URL will not work on a secure folder.

## Generating a Key Pair

As part of the process of enabling Secure Sockets Layer (SSL) security on your Web server, you need to generate a key pair and then acquire an SSL certificate. The new Key Manager application (installed with the product and located in the Internet Server program group) simplifies this procedure.

#### To generate a key pair

1. In the Microsoft Internet Server submenu, click Key Manager, or click the Key Manager icon on the Internet Service Manager toolbar.

2. From the Key menu, click Create New Key.

3. In the Create New Key and Certificate Request dialog box, fill in the requested information, as follows:

Key Name

Assign a name to the key you are creating.

Password

Specify a password to encrypt the private key.

Bits

By default, Key Manager generates a key pair 1024 bits long. To specify a key that is 512 or 768 bits long, make the proper selection in this box. The more bits you specify, the greater your security. In international versions, the size of each key you create is 512 bits

Organization

Preferably International Organization for Standardization (ISO)-registered, top-level organization or company name.

Organizational Unit

Your department within your company, such as Marketing.

Common Name

The domain name of the server, for example, www. mycompany.com.

Country

Two-letter ISO Country designation, for example, US, FR, AU, UK, and so on.

State/Province

For example, Washington, Alberta, California, and so on.

Locality

The city where your company is located, such as Redmond or Toronto.

Request File

Type the name of the request file that will be created.

4. After filling out the form, click OK.

5. When prompted, retype the password you typed in the form, and click OK.

An icon appears as the key is being created. When the key has been created, a screen appears giving you information about new keys and how to obtain a certificate.

6. After reading the New Key Information screen, click OK.

7. To save the new key, from the Servers menu choose Commit Changes Now.

8. When asked if you want to commit all changes now, click OK.

Your key will appear in the Key Manager window under the name of the computer for which you created the key. By default, a key is generated on your local computer.

Note Do not use commas in any field. Commas are interpreted as the end of that field and will generate an invalid request without warning.

### Generating a Key Pair on Another Server

You can set up a key pair on another server and install the certificate there. From the Servers menu, click Connect to Server, and follow the previous procedure under “Generating a Key Pair.”

Once you have generated a key pair, you must get a certificate and then install that certificate with the key pair. For information about getting a certificate, see “Acquiring a Certificate” and “Installing a Certificate with a Key Pair.”

## Acquiring a Certificate

The key generated by Key Manager is not valid for use on the Internet until you obtain a valid certificate for it from a Certificate Authority, such as VeriSign. Send the certificate request file to the Certificate Authority to obtain a valid certificate. Until you do so, the key will exist on its host computer, but cannot be used. For instructions on acquiring a VeriSign certificate refer to VeriSign’s Web site at http://www.verisign.com/microsoft/.

## Installing a Certificate with a Key Pair

After you complete your certificate request, you will receive a signed certificate from the Certificate Authority (consult your Certificate Authority for complete details). The key manager program will create a file similar to the following example:

`-----BEGIN CERTIFICATE-----
JIEBSDSCEXoCHQEwLQMJSoZILvoNVQECSQAwcSETMRkOAMUTBhMuVrM
mIoAnBdNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQ
QLExNQZXJzb25hIENlcnRpZmljYXRlMSQwIgYDVQQDExtPcGVuIE1hc
mtldCBUZXN0IFNlcnZlciAxMTAwHhcNOTUwNzE5MjAyNzMwWhcNOTYw
NTE0MjAyOTEwWjBzMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIER
hdGEgU2VjdXJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydG
lmaWNhdGUxJDAiBgNVBAMTG09wZW4gTWFya2V0IFRlc3QgU2VydmVyI
DExMDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDU/7lrgR6vkVNX40BA
q1poGdSmGkD1iN3sEPfSTGxNJXY58XH3JoZ4nrF7mIfvpghNi1taYim
vhbBPNqYe4yLPAgMBAAEwDQYJKoZIhvcNAQECBQADQQBqyCpws9EaAj
KKAefuNP+z+8NY8khckgyHN2LLpfhv+iP8m+bF66HNDUlFz8ZrVOu3W
QapgLPV90kIskNKXX3a
------END CERTIFICATE-----`

#### To install a certificate

1. In the Internet Server program group, click Key Manager.

2. In the Key Manager window, select the key pair that matches your signed certificate.

If you had backed up the key pair file, you have to load it first. For instructions, see “Loading a Key Pair File” earlier in this chapter.

3. From the Key menu, choose Install Key Certificate.

4. Select the Certificate file from the list (Certif.txt, for example), and click Open.

5. When prompted, type the password that you used in creating the key pair.

The key and certificate are combined and stored in the registry of the server.

6. From the Servers menu, choose Commit Changes Now.

7. When asked if you want to commit all changes now, click OK.

You can back up a key and certificate combination by following the procedure under “Backing Up Keys” earlier in this chapter.

Note If you do not specify an IP address while installing your certificate, the same certificate will be applied to all virtual servers created on the system. If you are hosting multiple sites on a single server, you can specify that the certificate be used only for a particular server IP address by adding the IP address, for example:

`10.191.28.45`

## Configuring a Directory to Require SSL

Once you have applied the certificate, you must enable the SSL feature from Internet Service Manager. SSL can be required on any virtual folder available in your Web site and is configured on the Directories property sheet.

#### To require SSL

1. In Internet Service Manager, double-click the WWW service to display its property sheets, then click the Directories tab.

2. Select the folder that requires SSL security, then click Edit Properties.

3. Select the Require secure SSL channel option, and then click OK.

## Moving a Key Pair to Another Server

After creating a key pair, you can use Key Manager to move the key pair to another server.

#### To move a key pair to another server

1. From the Servers menu, click Connect to Server, type the name of the server you want to move the key pair to, and click OK.

The server name appears in the list of servers (the left column).

2. Select the key you want to move.

3. From the Edit menu, click Cut.

4. Select the server you want to move the key pair to.

5. From the Edit menu, click Paste.

You can copy a key pair to another server with the same procedure by substituting the Copy command for Cut.

## Backing Up Keys

With Key Manager you download key information from the registry into a file on your hard disk and then copy this file or move it to a floppy disk or tape for safekeeping. You can back up a private key pair file or a key with an installed certificate.

#### To back up a key or a private key pair file

1. From the Key menu in Key Manager, choose Export Key and then Backup File.

2. After reading the warning about downloading sensitive information to your hard disk, click OK.

3. Type the key name in the File Name box, and click Save.

The file is given a .req file-name extension and is saved to your hard disk drive. You can then copy it or move it to a floppy disk or magnetic tape.

## Loading Backed Up Keys

You can load backed-up keys or private key pair files into Key Manager with the Import command.

#### To load a backed-up key

1. From the Key menu in Key Manager, choose Import Key and then Backup File.

2. Select the file name from the list, and click Open.

## Loading a Key Created with Keygen.exe and Setkey.exe

If you have generated a key pair from the command line with the Keygen.exe command and installed a certificate with Setkey.exe, you can load them into Key Manager with the Import command.

#### To load a key

1. From the Key menu in Key Manager, choose Import Key and then KeySet.

2. In the Private Key Pair File box, type the file name for the key pair or click Browse and select the file.

3. In the Certificate File box, type the file name for the certificate or click Browse and select the file.

4. Click OK.

5. Type the password for the private key in the Private Key Password box, and click OK.

## Suggestions for SSL Configuration and Operation

Microsoft recommends that you use separate content directories for secure and public content (for example, C:\InetPub\Wwwroot\Secure-Content and C:\InetPub\Wwwroot\Public-Content).

Save your key file in a safe place in case you need it in the future. It is a good idea to store your key file on a floppy disk and remove it from the local system after completing all setup steps. Do not forget the password you assigned to the key file.

© 1996 by Microsoft Corporation. All rights reserved.