Securing SharePoint Traffic with SSL Encryption

By default, SharePoint is configured to use Integrated Windows authentication. This form of authentication works fine if access to the server is over a trusted internal network, but is not feasible for access over the Internet.

Because of this limitation, a form of authentication that can be sent across the Internet must be used. This effectively limits the SharePoint server to using Basic Authentication, which is supported by most web browsers and devices. The problem with Basic Authentication, however, is that the username and password that the user sends is effectively sent in clear text and can be intercepted and stolen in transit. In addition, documents and other confidential information are transmitted in clear text, a huge security issue.

The solution to this problem is to use what is known as Secure Sockets Layer (SSL) encryption on the traffic. SSL encryption is performed using Public Key Infrastructure (PKI) certificates, which work through the principle of shared-key encryption. PKI SSL certificates are widely used on the Internet today; any website starting with a https:// uses them, and the entire online merchant community is dependent upon the security of the system.

For SharePoint, the key is to install a certificate on the server so that the traffic between the device and the server is protected from prying eyes. There are effectively two options to this approach, as follows:

• Use a third-party certificate authority— A common option for many organizations is to purchase a certificate for SharePoint from a third-party trusted certificate authority (CA), such as Verisign, Thawte, or others. These CAs are already trusted by a vast number of devices, so no additional configuration is required. The downside to this option is that the certificates must be purchased and the organization doesn’t have as much flexibility to change certificate options.

• Install and use your own CA— Another common approach is to install and configure Windows Server 2008 R2 Active Directory Certificate Services (AD CS) to create your own CA within an organization. This gives you the flexibility to create new certificates, revoke existing ones, and not have to pay immediate costs. The downside to this approach is that no browsers will trust the certificate by default, and error messages to that effect will be encountered on the devices unless the certificates are manually trusted or forced out to client domain members via Active Directory Group Policy Objects.