CHAPTER 5: Securing Your Site Against Intruders

### CHAPTER 5:

# Securing Your Site Against Intruders

Securely Configuring Your System
How Peer Web Services Security Works
Securely Configuring the WWW Service
Securing Data Transmissions with Secure Sockets Layer (SSL)

Connecting computers to the Internet or an intranet provides for some very powerful and useful scenarios. When you connect to the Internet, you can communicate with millions of people and computers worldwide using Transfer Control Protocol/Internet Protocol (TCP/IP). This broad flexibility imposes a degree of risk — not only can you communicate with people and other systems, it is also possible for users to attempt to initiate communication with your system. Although connecting to Web servers on the Internet or on an intranet 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.

Although security is important even for a personal Web site that is accessed only by members of your work group, your security configuration is crucial for safe operation of your system on the Internet. Although it is unlikely that your site will be maliciously tampered with, Internet servers are available to the general public and there may be some degree of public intrusion. This chapter will help you effectively use Windows NT security and Peer Web Services 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 source before installing your site on the Internet.

This chapter explains:

- General Windows NT security and how to apply it to your site.

- How Peer Web Services security works.

- How to securely configure the WWW service.

# Securely Configuring Your System

Windows NT provides user-account security and Windows NT File System (NTFS) file-system security. You can use the following topics as a checklist to ensure you have effectively used User Accounts and NTFS to secure Windows NT. Additionally, you can prevent security breaches by properly configuring the services running on your computer.

## Preventing Intrusion by Setting Up User Accounts

Windows NT security helps you protect your computer and its resources by requiring assigned user accounts. You can control access to all computer resources by limiting the user rights of these accounts.

Every operation on a computer running Windows NT identifies who is doing the operation. For example, the username 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 right to “Log on locally,” which is required for users to use Internet services.

### Allowing Anonymous Access with the
IUSR_computername Account

An anonymous connection is processed when a client request does not contain a username and password. This occurs in the following cases:

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

- All gopher requests.

- A Web (HTTP) request’s headers do not contain a username and password (this is the default on new Web connections with most browsers).

Each Internet service maintains a Windows NT username and password to be used for the processing of anonymous requests. When an anonymous request is received, the service “impersonates” the user configured as the “anonymous logon” user. The request will succeed if the “anonymous logon” user has permission to access the requested resource, as determined by the resource’s Access Control List (ACL). For the WWW service only, if the user does not have permission to access the resource, the response returned to the client contains a list of supported authentication schemes for gaining access to the resource, based on system configuration.

The “anonymous logon” user account can be viewed and modified on the Service property sheet of each Internet service. Each Internet service running on the same computer can use the same, or different, “anonymous logon” user accounts. Including the “anonymous logon” user account in file or directory ACLs allows for precise control of the resources available to “anonymous” clients.

The “anonymous logon” user account specified must be a valid Windows NT user account on the Web server, and the password specified must match the password for this user in that computer’s user database. User accounts and passwords are configured using the Windows NT User Manager. The “anonymous logon” user account must have the user right (in the User Manager Policies Menu) to “Log on Locally.”

The IUSR_computername account is created during Internet services 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 using the IUSR_computername account. The IUSR_computername account is permitted only to log on locally on the system providing the Internet services. No network rights are granted that could allow an unauthorized user to damage your server or its files.

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.

This account will, in most cases, give anonymous client requests access to public content published on the server. Run the Network applet in Control Panel to see the computer name configured for the Windows NT computer.

A randomly generated password is created for the “IUSR_computername” account. If you need to change the password for this account, you must specify the new password for the account in User Manager, and then on the Service sheet of the Internet Service Manager, for each Internet service installed.

When Peer Web Services for Windows NT is installed, the account is created on the local computer.

### Requiring a Username and Password

If you restrict Internet services to “authenticated” clients, users must supply a valid Windows NT username and password. The WWW service provides two forms of authentication: Basic and NT Challenge/Response (sometimes referred to as NTLM).

Basic authentication does not encrypt your username and password before transmission.

Warning If you use basic authentication, you will send your Windows NT username and password in clear text (unencrypted) over public networks. Intruders could easily learn usernames and passwords.

Microsoft recommends the Windows NT Challenge/Response method of password authentication.

Windows NT authentication, currently supported only by Microsoft Internet Explorer version 2.0 or later, encrypts the username and password, providing secure transmission of usernames and passwords over the network.

With both basic authentication and Windows NT authentication, no access is permitted unless a valid username and password is 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 IUSR_computername access and authenticated access enabled at the same time.

#### Client Requests Containing Credentials

A request containing credentials is one of the following:

- An FTP client logs on with a valid Windows NT username and password. This requires that the FTP service “Allow only anonymous connections” check box be cleared.

Warning FTP sends passwords across the network in clear text.

- A WWW (HTTP) request’s headers contain a username and password (this is generally in response to an “access denied” response from a server). This is HTTP basic authentication.

Warning HTTP basic authentication sends passwords across the network in clear text.

- A Web browser supports Windows NT Challenge/Response authentication protocol, and an anonymous client request is denied access to a resource. In this case, the browser automatically sends the Windows client’s username and password to the Web server using the Windows NT Challenge/Response authentication protocol. In this release, the only browser that supports Windows NT Challenge/Response authentication protocol is Internet Explorer 2.0 or later.

When an Internet service receives a client request that contains credentials (a username and password), the “anonymous logon” user account is not used in processing the request. Instead, the username 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 username and password, the request fails, and an error notification is returned to the client.

For the WWW (HTTP) service only, 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 service supports. This is determined by the configuration of the WWW service’s authentication features. If the response indicates to the client that the service is configured to support HTTP basic authentication, most Web browsers will display a username and password dialog box, and reissue the anonymous request as a request with credentials, including the username 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 username and encrypted password from the client to the service. The client request will then be reprocessed, using the client’s user information. 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 Web server computer, 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.

#### Internet Service Manager Authentication Options

In addition to the “anonymous logon” username and password fields, the Service property sheet of Internet Service Manager contains the following authentication options:

##### WWW

- Allow Anonymous When this check box is selected, anonymous connections are processed, and the “anonymous logon” username and password are used for these connections. When this check box is cleared, all anonymous connections are rejected, and basic or Windows NT Challenge/Response authentication protocol is required to access content.

- Basic When this check box is selected, the WWW service will process requests using basic authentication.

Warning Basic authentication sends Windows NT usernames and passwords across the network without encryption. This check box is cleared by default for security reasons.

- Windows NT Challenge/Response When this check box is selected, the service will honor requests by clients to send user account information using the Windows NT Challenge/Response authentication protocol. This protocol uses a one-way hash to prevent passwords from being transmitted across the network. The Windows NT Challenge/Response authentication process is initiated automatically as a result of an “access denied” error on an anonymous client request. Currently, Windows NT Challenge/Response authentication protocol works only with Internet Explorer 2.0 or later.

Note If the “Basic” and “Windows NT Challenge/Response” check boxes are both cleared (and the “Allow Anonymous” check box is selected), all client requests are processed as anonymous requests. In this case, if the client supplies a username and password in the request, this username and password are ignored by the WWW service. The “anonymous logon” user account will be used to process the request.

##### FTP

- Allow Anonymous Connections When this check box is selected, FTP logons in which the user enters a username of “anonymous” will be processed. These anonymous connections will be processed on behalf of the Windows NT user account specified on the Service property sheet. When this check box is cleared, users will be required to enter valid Windows NT usernames and passwords to log onto the FTP service.

- Allow only anonymous connections When this check box is selected, user logons with a username other than “anonymous” will be rejected.

Warning FTP usernames and passwords are sent across the network in clear text. When this check box is cleared, Windows NT passwords will be sent to the server without encryption. This check box is selected (enabled) by default for security reasons.

### Choose Difficult Passwords

The easiest way for someone to gain unauthorized access to your system is with a stolen or easily guessed password. Make sure that all passwords used on the system, especially those with administrative rights, have difficult-to-guess passwords. In particular make sure to 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 the User Manager utility, or at the system logon prompt.

### Maintain Strict Account Policies

The User Manager utility provides a way for the system administrator to specify how quickly account passwords expire (which forces users to regularly change passwords), and other policies such as how many bad logon attempts will be tolerated before locking a user out. Use these policies to manage your accounts, particularly those with administrative access, to prevent exhaustive or random password attacks.

### Limit the Membership of the Administrator Group

By limiting the members of the Administrator group, you limit the number of users who might choose bad passwords and expose your system.

### Setting WWW Directory Access

When creating a Web publishing directory in Internet Service Manager, three access permissions can be selected via check boxes on the Directories dialog box. The setting of these access permissions applies to the defined home directory or virtual directory, and all of its subdirectories. The permissions are:

#### Read

In order for files stored in a directory (home directory or virtual directory) to be downloaded to a client, the directory’s Read permission must be enabled. If a client sends a request for a file that is in a directory without Read permission, the Web server will return an error. Directories containing information to publish (HTML files, for example) would typically have this permission enabled. Directories containing Common Gateway Interface (CGI) applications and Internet Server Application Program Interface (ISAPI) DLLs would typically have this permission disabled, to prevent clients from downloading the application files.

#### Execute

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

- The filename 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 (in this example, \Scripts), and the directory 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 is stored in a directory of the Web publishing tree that has the Execute permission enabled. The service, upon receiving the request, will use the filename-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. Please see filename-extension mapping for more information.

#### Require secure SSL channel

This option must be selected to require encrypted communication for a directory. For more information on Secure Sockets Layer (SSL), see “Securing Data Transmissions with Secure Sockets Layer (SSL),” later in this chapter.

## NTFS File Security

The WWW, gopher, and FTP services are fully integrated with Windows NT user accounts and file access permissions.

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

In addition to user accounts, 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.

The NTFS file system allows ACLs to be assigned to files and directories. ACLs grant or deny access to the associated file or directory 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 directory ACLs are configured by using the Windows NT File Manager.

The NTFS file system gives you very granular 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 Peer Web Services settings, the strictest setttings will be used.

You should review the security settings for all Microsoft Peer Web Services directories and adjust them appropriately. Generally you should use the settings in the following table:

Directory Type | Suggested Access

content | Read access

programs | Read and Execute access

databases | Read and Write access

### Controlling Security by ACL on NTFS Drives

###### »&#nbsp;&#nbsp; To secure your files on a Windows NT 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 the Windows NT File Manager, select the directory you want to secure (select your site root to secure the entire site).

3. From the Security menu, choose Permissions.

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

5. In the Add Users and Groups dialog box, add the users that you want to grant access to.

6. Click OK.

7. In the Directory Permissions dialog box, select the users and groups that you want to assign permission to.

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

9. Click OK.

### Enable Auditing

You can enable auditing of NTFS files and directories on Windows NT through the File Manager. You can review the audit records periodically to ensure that no one has gained unauthorized access to sensitive files.

## 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 applet 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 applet 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.

### 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. It is also wise to double-check the permissions set on the files contained in the shares’ directories to ensure that you have set them correctly.

# How Peer Web Services for Windows NT Security Works

Peer Web Services for Windows NT integrates Windows NT authentication (username and password) security and NTFS file system security.

A simple overview of the security process used on each request is presented in the following illustration.

## Username Authentication

By default, all requests use anonymous access through the IUSR_computername user account created during Peer Web Services setup. This account is a user account and is granted the right to log on locally.

Username authentication is probably most useful if you want to control access to your server by individual user or group.

## Internet Service Permissions

When creating a Web publishing directory in Internet Service Manager, three access permissions can be selected by selecting or clearing check boxes on the Directories dialog box. The setting of these access permissions applies to the defined home directory or virtual directory, and all of its subdirectories. The permissions are:

### Read

In order for files stored in a directory (home directory or virtual directory) to be downloaded to a client, the directory’s Read permission must be enabled. If a client sends a request for a file that is in a directory without Read permission, the Internet service will return an error. Directories containing information to publish (HTML files, for example) would typically have this permission enabled. Directories containing CGI applications and Internet Server Application Program Interface (ISAPI) DLLs would typically have this permission disabled, to prevent clients from downloading the application files.

### Execute

A client request can invoke a CGI application or ISAPI application in one of two ways:

- The filename 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 (in this example, \Scripts), and the directory 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 is stored in a directory of the Web publishing tree that has the Execute permission enabled. The service, upon receiving the request, will use the filename-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. Please see “Associating Interpreters with Applications (Script Mapping)” in Chapter 10, “Configuring Registry Entries,” for more information.

### Require secure SSL channel

This option must be selected to require encrypted communication for a directory. For more information on Secure Sockets Layer (SSL), see “Securing Data Transmissions with Secure Sockets Layer (SSL),” later in this chapter.

Note that neither the FTP nor gopher services support SSL.

## NTFS Permissions

On NTFS drives you must also ensure that similar permissions are set on directories.

# Securely Configuring the WWW Service

In addition to implementing the previous suggestions on securing Windows NT, you can further enhance your security by using Internet Service Manager to configure the WWW service.

## Controlling Access by Username

To gain access to files, users must be identified with a valid username and password.

If you are allowing anonymous logon using the IUSR_computername account, you should first ensure that computer-wide User Rights (in the User Manager Policies menu) do not allow the IUSR_computername account, the Guests group, or the Everyone group any right other than to “Log on Locally.” Next, ensure that the file permissions set in the Windows NT File Manager are appropriate for all content directories used by Microsoft Peer Web Services.

If you allow basic or Windows NT Challenge/Response password authentication, users can supply a username and password to gain access to areas that require specific authorization. The usernames must be valid usernames on the computer running Peer Web Services, or in a Windows NT domain accessible from that computer.

###### »&#nbsp;&#nbsp; To set username and password security

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

2. In the Anonymous Logon box, type the username and password to be used by the WWW service when accessing resources on behalf of an anonymous client.

This account must be a valid account in the Windows NT User Manager.

3. In the Password Authentication box, choose the following options:

Allow Anonymous.

Basic (clear text)

Windows NT Challenge/Response for encrypted authentication. This option works only for clients using Internet Explorer version 2.0 (or later).

4. Click OK.

## Disable Directory Browsing

Unless it is part of your strategy, you should disable directory browsing on the Directories property sheet. Directory browsing exposes the entire file structure; if it is not configured correctly, you run the risk of exposing program files or other files to unauthorized access.

## Other Authentication Issues

This section gives further suggestions for securing your Web site.

### “INTERACTIVE” and “NETWORK” Users

If you use the predefined Windows NT user accounts “INTERACTIVE” and “NETWORK” for access control, your use of these accounts may affect client access to some resources. 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 using Windows NT Challenge/Response authentication protocol, the file must be accessible by the NETWORK user.

### Log on Locally

In User Manager, when configuring a Windows NT user account to be used either as the Peer Web Services “anonymous logon” account, or as a user account specified by client requests using HTTP Basic authentication, be sure that the user account is granted the “Log on locally” User Right. This is specified in the Policies menu of the User Manager.

### Customized Authentication

If you need a WWW request authentication scheme not supported by the service directly, obtain a copy of the ActiveX 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 ActiveX SDK can be found at http://www.microsoft.com/intdev.

# Securing Data Transmissions with
Secure Sockets Layer (SSL)

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

Peer Web Services for Windows NT 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 World Wide 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 (usernames 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.

Enabling SSL security on a Web server involves 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 directory.

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

- You can enable SSL security on the root of your Web home directory (\Wwwroot by default) or on one or more virtual directories.

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

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

- SSL security is enabled and disabled by using Internet Service Manager.

## How to Acquire an SSL Digital Certificate

As part of the process of enabling Secure Sockets Layer (SSL) security on your Internet 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 Peer Web Services program group) simplifies this procedure.

### Generating a Key Pair

Use Key Manager to create two files. The first file is a key file containing the key pair. The second file is a certificate request file.

###### »&#nbsp;&#nbsp; To generate a key pair

1. In the Peer Web Services program group, click Key Manager.

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 specifiy a key that is 512 or 768 bits long, make the proper selection in this box.

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. Do not abbreviate.

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. Click OK.

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

Your key will appear in the Key Manager window under the computer name.

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.

### Acquiring a Certificate

The key generated by Key Manager is not valid for use on the Internet until you obtain a valid key certificate for it from a key authority. Send the certificate request file to your key authority service to obtain a valid certificate. Until you do so, the key will exist on its host computer, but cannot be used.

Contact a certifying authority such as VeriSign. Instructions for acquiring a VeriSign certificate can be found on VeriSign’s Web site, www.verisign.com.

### Applying Your Certificate to Your Server

After you complete your certificate request, you will receive a signed certificate from the certification authority (consult your certification authority for complete details). It will look something like the following example:

`-----BEGIN CERTIFICATE-----`

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

------END CERTIFICATE-----

Copy and save the text to a file, using a tool such as Notepad, giving it a name you can remember (for example, Certif.txt). Then use Key Manager to install your signed certificate on the server.

###### »&#nbsp;&#nbsp; To install a certificate

1. In the Peer Web Services program group, click Key Manager.

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

3. Follow the on-screen instructions.

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 only be used for a given IP address by adding the IP address, for example: :
`10.191.28.45`

### Configuring a Directory to Require SSL

Once the certificate has been applied, the SSL feature is enabled from Internet Service Manager for the WWW services. SSL can be required on any virtual directory available through the Internet server and is configured on the Directories pane of the Service property sheet.

## Suggestions for SSL Configuration and Operation

Microsoft recommends that you use separate content directories for secure and public content (for example, C:\Inetsrv\Wwwroot\Secure-Content and C:\InetsrvWwwroot\Public-Content). It is important to avoid having a server directory not protected by SSL as a parent for a secure directory.

It is suggested that you 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.