Microsoft Internet Security and Acceleration Server 2000 SharePoint Portal Server Deployment Kit

Chapter 5

Configuring and Implementing Secure Sockets Layer (SSL) for SharePoint Web Sites

Martin Grasdal

Dr. Thomas W Shinder

December 2003

Table of Contents

Abstract 3

Overview of Public Key Infrastructure. 4

Step-by-Step How To: Implementing an Enterprise Root Certificate Authority. 8

Step-by-Step Background Information. 8

Installing and Configuring an Enterprise Root CA. 10

Enabling Secure Sockets Layer on SharePoint Web Site. 15

Summary. 26

Abstract

Whenever there is concern regarding confidentiality and integrity of data being sent between the SharePoint Web site and external clients, the SharePoint Web site should be configured with a digital X.509 certificate to enable SSL encryption. This chapter provides an overview of SSL and public key infrastructure and includes detailed step by step example of how to configuration secure SSL protected SharePoint Web sites.

This chapter demonstrates how to enable and configure digital certificates to ensure traffic passing between a SharePoint Portal server and an external client on the Internet is encrypted. The first part of the chapter provides an overview of the need for encryption and the basic elements of a Public Key Infrastructure. This is followed by step-by-step instructions that illustrate the process for installing and configuring an Enterprise Certification Authority to create certificates for use on SSL-enabled web sites. Following this is another set of instructions that demonstrate how to configure a virtual Web site to use digital certificates to encrypt traffic.

Overview of Public Key Infrastructure

External clients will likely use Basic Authentication to authenticate with the SharePoint 2003 Web site over the Internet. Although Basic Authentication has an advantage over Windows Integrated Authentication (WIA) using NTLM in that it supports delegation of credentials, it is far less secure. NTLM authentication uses a challenge handshake mechanism that ensures passwords are never sent across the wire. However, Basic Authentication sends both username and password in clear text to the Web server. Passing user name and password over the Internet “in the clear” increases the likelihood of these credentials being stolen.

Regardless of the authentication protocols clients and servers use, traffic passing between the client and the server lacks confidentiality and is potentially vulnerable to unwanted inspection and modification. For example, when a client requests a document from a SharePoint Web site, that document is forwarded to the client using unencrypted HTTP. Anyone who has access to the data stream between the client and server can capture and view this traffic. In addition, integrity of the data is potentially at risk through man-in-the-middle attacks. A man-in-the-middle attack takes place when an eavesdropper can impersonate one of the entities in the conversation and alter or destroy messages.

To ensure confidentiality and integrity of data, it is necessary to encrypt traffic passing between client and server. The mechanism for securing Web sites is Secure Sockets Layer/Transport Layer Security (SSL/TLS), often referred to as SSL. When SSL is enabled on Web sites, users gain access to the Web site by entering URLs that begin with HTTPS, rather than HTTP.

When a client connects to an SSL-enabled Web site, the following process for encrypting the traffic takes place:

The client sends an initial message to the Web server to establish the connection.
In response, the Web server sends the client a digital certificate containing the public key and other information to initiate an encryption process known as Public/Private or Asymmetric Key Encryption. Asymmetric Key encryption relies on Public/Private key pairs for encryption, decryption, hash-based verification of data integrity, and non-repudiation. When a message is encrypted with the public key (which is potentially available to anyone), only the private key of the key pair can decrypt the message. (Asymmetric key encryption relies on sophisticated mathematical algorithms and extremely large prime numbers, making it extremely difficult to compromise.)
The client performs a number of checks on the digital certificate, extracts the public key from the digital certificate, generates a session key of a certain length, encrypts the session key with the digital certificate, and then sends encrypted session key back to the Web server.
The Web server uses its private key to decrypt the session key. Now both entities have a session key that is known only to them through a highly secure encryption mechanism.

The Web server and the client use the session key to perform symmetric encryption of the data passing between them for the duration of the session. (Symmetric key encryption is less resource intensive than Asymmetric key encryption and the primary reason it is used as a mechanism to encrypt the session.)

The session key used to encrypt data lives only for a brief period of time. For example, if the user closes the browser and reconnects to the Web site, the process begins all over again. This mitigates symmetric key encryption and man-in-the-middle vulnerabilities.

Implementing SSL requires an X.509 digital certificate is installed on the Web site. The X.509 digital certificate is issued by an entity known as a Certificate Authority (CA). For e-commerce and other SSL-enabled Web sites are available to the general public, a commercial CA usually issues the certificate (for a fee) to the Web site. The reason a 3^rd-party commercial CA is used is that it is more likely to be mutually trusted by both the Web site and the external client. This is analogous to hiring someone based on a mutual friend’s recommendation—the employer is more likely to offer a job to a candidate because he or she trusts the person who made the recommendation; the candidate is more likely to accept the position for the same reason.

Windows operating systems come with a pre-configured list of trusted Certificate Authorities. So, when a user connects to an SSL-enabled Web site using a certificate issued by one of these CAs, the encrypted session is established seamlessly without additional prompting of the user. One place that you can view the pre-configured list of trusted root CAs is Internet Explorer, as in Figure 1 below.

To view the pre-configured list of trusted CAs, open Internet Explorer, click on Tools | Internet Options, click on the Content tab, click Certificates, and then click on the Trusted Root Certification Authorities tab.

Figure 1 Viewing Trusted Root Certification Authorities

However, it is possible using Windows to create an corporate Certificate Authority to issue certificates for use by internal and external servers and clients. Advantages of having an internal CA are

· Reduced costs

· Full control over digital certificates in the environment

However, the disadvantage is that a private CA is not automatically trusted by external clients and will cause a warning message to appear when the client connects to the SSL-enabled site. (See Figure 16 toward the end of this document for a sample warning message.) External users can configure their computers to trust the private CA; however, this requires that they manually perform a number of steps to install the root CA certificate.

For this reason, private CAs are less likely to be used to issue digital certificates to secure anonymous, publicly available Web sites. That said, a private CA is a useful solution if one of its purposes is to enable SSL on Web sites that are accessed only by employees or business partners.

A Windows 2000 or Windows Server 2003 server Certificate Authority can be set up in one of four possible configurations to create a Public Key Infrastructure (PKI):

· Enterprise root CA
Requires using Active Directory. An Enterprise root CA is the highest authority in the PKI hierarchy. Although it can issue certificates to Web servers to enable SSL and to clients for digital certificate client authentication, its primary and recommended use is to authorize other subordinate or intermediate CAs issuing these certificates. The advantage here is that if the subordinate CA is compromised, its certificate can be revoked by the root CA. An Enterprise CA issues a certificate to itself to be authorized. Because Enterprise CAs are integrated with Active Directory, it is possible to use more advanced features such as auto-enrollment. Auto-enrollment enables clients to request and install certificates from the CA automatically, and also enables the use of extended certificate templates.

· Enterprise subordinate CA
Requires the use of Active Directory. An Enterprise subordinate CA is authorized by an Enterprise root, Stand-alone root, or other subordinate CA. The digital certificate used to authorize a subordinate CA contains the hierarchical path back to the root CA. Furthermore, all certificates the subordinate CA issues contain this path back to the root CA. When the certifying CA revokes the certification for the subordinate CA, all certificates that the subordinate CA has issued are also revoked. In highly secure environments, Enterprise subordinate CAs receive their authorization from a Stand-alone root CA, which is subsequently taken offline and placed in a secure location.

· Stand-alone root CA
Does not require the use of Active Directory. A Stand-alone root CA is the highest authority in a PKI infrastructure and issues its own authorizing certificate to itself. The functionality of stand-alone CAs is more limited than Enterprise CAs. For example, they can not issue certificates based on extended templates, nor is it possible for them to leverage the Active Directory to issue certificates through auto-enrollment. Users must go through a Web-based interface to request certificates. Furthermore, CA administrators must approve these requests before certificates can be issued (by default). A stand-alone root can be configured as an offline root CA. That is, it is kept offline in a highly secure location and is brought online only to perform tasks related to the certification of subordinate CAs and the updating of Certification Revocation Lists (CRLs).

· Stand-alone subordinate CA
Does not require Active Directory. Shares the characteristics of a stand-alone root CA. However, it receives its authorization from another CA.

The topic of a Public Key Infrastructure and Certificate Authorities is large and complex. Large organizations should research this topic thoroughly before planning a PKI implementation. Smaller organizations can use a single CA to manage most of their PKI requirements.

The Microsoft Web site contains many excellent resources for helping you understand, plan, and implement a PKI. A good starting point is the Microsoft Whitepaper, An Introduction to the Windows 2000 Public-Key Infrastructure. Windows Server 2003 contains many significant enhancements to Certificate Services. For example, it is now possible to issue both computer and user certificates through auto-enrollment if Certificate Services is installed on the Enterprise Edition of Windows 2003 Server.

Step-by-Step How To: Implementing an Enterprise Root Certificate Authority

This section of the document provides step-by-step instructions for installing Certificate Services and configuring a Windows 2003 Server as an Enterprise Root Certificate Authority. One of the purposes of the Enterprise root CA that is configured in this demonstration is to issue certificates to enable SSL on a SharePoint Web site and an ISA Server in subsequent demonstrations. It is not recommended that you use a root CA to issue certificates for users or computers.

Note:
In a large scale very high security production environment, you should avoid using a root CA to issue computer or user certificates. Instead, as a recommended minimum, you should implement a root CA to authorize a subordinate CA that, in turn, subsequently issues user or computer certificates. For environments that have more stringent security requirements, you may wish to configure an offline standalone root CA that authorizes intermediate CAs. These intermediate CAs subsequently authorize subordinate CAs that issue the user or computer certificates.

Step-by-Step Background Information

The test lab used to demonstrate these step-by-step instructions has the following configuration:

· Internal Network
The internal network uses the 172.16.1.0/24 network ID. The default gateway for the network is 172.16.1.1, which is the internal IP address of the ISA Server.

· External Network
The external network uses a 192.168.100.0/24 network ID.

· Internal DNS and Active Directory Namespace
Internal.net is used as the Active Directory and DNS namespace for the internal network.

· Active Directory
A Windows 2003 Active Directory domain controller named Ad1.internal.net is used to provide directory and DNS services. DNS is set up with root hints and forwarding to support resolution to the external network and the Internet. The IP address of the domain controller is 172.16.1.10.

· Domain Controller Virtual Web Site Configuration.
To support both Active Directory and Web-based enrollment methods for issuing certificates to users and computers, IIS 6.0 was installed on Windows 2003 domain controller, Ad1.internal.net. Active Server pages are required to support Web-based certificate enrollment. Specifically, the virtual Web site is configured with the following components:

o Application Server with the following components:

§ Microsoft ASP.NET

§ Enable COM+ Components

§ Microsoft Internet Information Services with the following components:

· Common Files

· Internet Information Services Manager

· World Wide Web Service with the following components:

o Active Server Pages

o World Wide Web Service

· External DNS Namespace
External.net is used as the DNS namespace for external clients that connect to resources published through ISA Server 2000 firewall. DNS zone files for external.net are located on the external network. A single host record points to external IP address of ISA Server 2000 firewall to resolve the Fully Qualified Domain Name (FQDN) extranet.external.net for access to extranet SPS web site.

· SharePoint Portal Server 2003 Configuration.
SharePoint Portal Server 2003 installed with a co-located WMSDE database is set up on a Windows 2003 computer named Sps.internal.net.

· SharePoint Server Virtual Web Site Configuration.
IIS 6.0 was installed on the Windows Server 2003 server as per the SharePoint Portal Server 2003 prerequisites found in the SharePoint Portal Server 2003 Help file. An additional virtual Web site was set up on the SPS computer to support both intranet and extranet access to the same SPS configuration and content SQL databases. (Please see the SharePoint Portal Server 2003 help files for instructions on creating this configuration.) The intranet virtual web site is located at 172.16.1.11 and is configured to use Windows Integrated Authentication only. The extranet virtual web site is located at 172.16.1.12 and is configured to use Basic Authentication only. No DNS Resource Records resolve to the 172.16.1.12 address.

· ISA Server 2000 firewall Configuration. A stand-alone ISA Server 2000 with Service Pack 1 has been set up in integrated mode (Firewall and Web Proxy service) on a Windows 2000 member server with Service Pack 4. The basic configuration of ISA Server is as follows:

o External NIC configuration:

§ IP address: 192.168.100.22/24

§ Default Gateway: 192.168.100.254/24

§ NetBIOS disabled

§ Registration of external IP address in Dynamic DNS zone disabled

§ DNS server: None

o Internal NIC configuration:

§ IP address: 172.16.1.1/24

§ Default Gateway: None

§ NetBIOS enabled

§ Registration of IP address in Dynamic DNS zone enabled

§ DNS server: 172.16.1.10

o ISA configuration details:

§ Local Address Table: 172.16.1.0 – 172.16.1.255

§ Packet Filtering: Enabled

§ Site and Content Rule: Default

§ Protocol Rule: Single rule added to provide access to all protocols

§ Destination Sets: Single Destination Set configured to support Web Publishing rule. Destination set points to extranet.external.net as FQDN.

§ Incoming Web Listener: Enabled with default settings. No authentication required.

§ Web Publishing Rule: Single Web publishing rule added to publish SPS extranet SharePoint virtual server (internal IP address = 172.16.1.12/24).

§ URLScan 2.5: Enabled using the URLScan IIS template (URLScan_iis.ini).

§ Client Configuration: All clients configured as SecureNAT clients.

Installing and Configuring an Enterprise Root CA

Before installing an Enterprise root CA, you will probably wish to install IIS 6.0 with Active Server pages enabled to take advantage of Web-based enrollment methods to issue certificates to users and computers. You can find details for the minimum IIS components in the Step-by-Step Background Information above. Once you have installed IIS, the procedure for installing an Enterprise root CA is as follows (using the Classic Start Menu view):

Click Start. Then navigate to Settings | Control Panel and click to open.
In Control Panel, double click on Add or Remove Programs.
In Add or Remove Programs, click on Add/Remove Windows Components. The Windows Components Wizard appears.
In the Windows Components Wizard, click on Certificate Services to install both subcomponents . The two subcomponents are Certificate Services CA and Certificate Services Web Enrollment Support. A warning informing you of the consequences of installing Certificate Services will appear, as in Figure 2 below.

Figure 2 Microsoft Certificate Services Warning

On the Microsoft Certificate Services warning, click Yes. You will be prompted to select the CA type, as in Figure 3 below.

Figure 3 Choosing Certificate Authority Type

Ensure that Enterprise root CA is selected and click Next. If you prefer, you can also choose to select Stand-alone root CA. However, some of the instructions that follow in this document depend on Certificate Services integration with Active Directory, which is possible only if you choose Enterprise root CA.

In the subsequent CA Identifying Information page, you will be prompted to enter a common name for the CA, as in Figure 4 below. This name is typically the NetBIOS or the FQDN of the computer on which you are installing the CA. The NetBIOS name of the computer in this demonstration is AD1. Enter either the NetBIOS or FQDN name in the Common name for this CA, accept the default of 5 years for the Validity Period and click Next.

Figure 4 CA Identifying Information Page

On the subsequent Certificate Database Settings page, click Next to accept the default locations for the certificate database, database log, and configuration information. You will be prompted with a warning indicating the IIS services will be stopped temporarily to complete the installation, as in Figure 5 below.

Figure 5 Stopping Internet Information Services To Complete CA Installation

Click Yes to stop Internet Information Services and complete the installation of the Enterprise root CA. If you have not previously installed support for Active Server Pages in IIS, you will be prompted with a warning about the security risks associated with Active Server Pages. If you see this warning, click Yes to enable Active Server Pages to complete the installation of the CA.
Click Finish on the Completing Windows Components Wizard.

You will want to confirm that Certificates Services with Web enrollment support is running. The quickest way to verify this is to open up the Certificate Services Web enrollment page.

To verify Certificate Services is running with Web enrollment support, open Internet Explorer from the computer on which you installed Certificate Services, type http://localhost/certsrv as the URL (or alternatively http://<computername>/certsrv) in the address bar and press Enter. The Web enrollment page should appear as in Figure 6 below.

Figure 6 Certificate Authority Web Enrollment Page

Once you have installed a Certificate Authority, you are now able to request and install a digital certificate to secure the SharePoint Web site using Secure Sockets Layer (SSL).

Enabling Secure Sockets Layer on SharePoint Web Site

This section shows you how to request an X.509 digital certificate from a CA and configure the Web site to use the certificate to secure the SharePoint Web site with SSL. Because the certificate request will be sent to an Enterprise CA from a member server of an Active Directory domain, the steps involved in making requesting and receiving the digital certificate are simpler and fewer than they would be if the request were sent to a standalone CA.

For example, because the SharePoint Web server is installed on a member server of a Windows 2003 domain, it is already a trusted computer. Therefore, the Enterprise CA automatically issues the certificate to the SharePoint server without intervention on the part of an administrator to approve the request.

The first step to enable SSL on the SharePoint Web site is to request an X.509 digital certificate from a CA.

Open the Internet Information Services MMC console, navigate to the virtual server that you wish to secure with SSL, right on the virtual server node, and click Properties.
From the Properties page for the virtual server, select the Directory Security tab, as in Figure 7 below.

Figure 7 Directory Security Tab of Virtual Web Site

In the Directory Security tab, click on Server Certificate in the Secure communications frame. The Welcome to the Web Server Certificate Wizard will appear.
Click Next in the Welcome to the Web Server Certificate Wizard. The Server Certificate page will appear, as in Figure 8 below.

Figure 8 Methods for Assigning a Certificate to a Web Site

On the Server Certificate page (Figure 8 above), ensure Create a new certificate is selected, and click Next.

If you already have a digital certificate you wish to use, other options may be more appropriate. The options are as follows:

Create a new certificate. Use this option if you do not already have a certificate you wish to use.
Assign an existing certificate. If you already have a digital certificate for this web server that is installed into the computer’s certificate store, use this option to bind the certificate to the virtual Web site.
Import a certificate from a Key Manager backup file. Use this option if you wish to import a certificate from an IIS 4.0 site.
Import a certificate from a .pfx file. Use this option if you have previously exported a digital certificate into a .pfx file. The .pfx file must have been exported with the private key to support this option.
Copy or Move a certificate from a remote server site to this site. Use this option if another server exists on the same internal network that already uses the certificate you want. This option is useful if you are setting up Network Load Balanced SharePoint servers in a Server Farm configuration.

In the Delayed or Immediate Request page, select Send the request immediately to an online certificate authority to send the request to an online Enterprise CA, as in Figure 9 below, and click Next.

If you do not have an Enterprise CA, or you wish to send the request later, select the option to Prepare the request now, but send it later. When you select this option, a text file will be created containing the certificate request. You can subsequently use this text file to make the request to a standalone CA using the Web enrollment Web pages.

Figure 9 Delayed or Immediate Request Page

In the Name and Security Settings, type in a “friendly name” for the certificate in the Name text box, accept the default Bit length of 1024 bits and click Next, as in Figure 10 below.

The name you enter should be informative to help you easily identify the certificate when you view certificates in the certificates store using the MMC Certificates snap in. The name has no effect on the operation of the certificate.

The bit length setting governs the strength of the encryption. The longer the bit length, the greater the level of encryption. Be aware that there is a trade off between performance and security. Encryption is a CPU-intensive process and a large value for a bit length will consume significantly more CPU cycles.

A cryptographic service provider (CSP) is a component that uses specific algorithms for performing encryption or authentication. A CSP is either software- or hardware- based. The default Windows CSP is an example of a software-based CSP. A smart card is an example of a hardware-based CSP. This type of CSP is known as a smart card cryptographic provider (SCCP). Typically, you would choose a specific CSP if you were using smart cards or other hardware devices that have the ability to perform cryptographic functions.

Figure 10 Name and Security Settings Page