In the last blog post, I’ve provided the step by step guide to deploy Work Folders in a test lab environment, where the client is using unsecure connections to the server, which means the server doesn’t require to have SSL certificate. While using unsecure connection simplifies the testing, it is not recommended for production deployment. In this blog, I will provide you a step-by-step guide on configuration of the SSL certificate on the Work Folders server, so that, the client will be able to establish the secure connection to the server using SSL.

Prerequisites

You will need the following setup:

1. Work Folders server set up and configured with at least one sync share. (Let’s name it as SyncSvr.Contoso.com)
2. One client device running Windows 8.1

How Work Folders uses certificate?

The Work Folder client server communication is built using secure HTTP 1.1. According to RFC 2818:

“In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.”

With Work Folders, when a client initiates an SSL negotiation with the server, server sends the certificate to the client, the client will evaluate the certificate, and only continue if the certificate is valid and can be trusted. You can find more details on the SSL handshake here.

Acquiring a certificate

In a production deployment, you will need to acquire a certificate from a known certificate authority (CA), such as from VeriSign or obtain a certificate from an online CA in your intranet domain such as your enterprise CA. There are a few things that Work Folders will verify in a server certificate, for example:

• Expired? : That the current date and time is within the "Valid from" and "Valid to" date range on the certificate.
• Server identity: That the certificate's "Common Name" (CN) or “Subject Alternative Name” (SAN) matches the host header in the request. For example, if the client is making a request to https://syncsvr.contoso.com, then the CN must also be https://syncsvr.contoso.com.
• Trusted CA? : That the issuer of the certificate is a known and trusted CA.
• Revoked? The certificate has been revoked.

This MSDN page more information on certificate validations: http://technet.microsoft.com/en-us/library/cc700843.aspx 

There are also a few different types of certificates you could acquire:

• One certificate with one hostname
• One certificate with multiple hostnames (SAN certificate)
• Wild card certificate for a domain (Wild card certificate)

You can evaluate the options based on:

1. The number of sync servers you are deploying.
2. Using Work Folders discovery? If you are planning to use discovery based on the user email address, you will need to publish https://WorkFolders.<domainname>, such as https://WorkFolders.contoso.com, all the sync servers that act as the discovery servers (by default, all sync server can perform discovery), will need to install a multiple hostnames (SAN) certificate which contains the hostname matches to the WorkFolders.contoso.com and the name used to access the sync servers.
3. Ease of management. Certificates are generally valid for 1 or 2 years — the more certificates you have, the more you need to monitor and renew.
4. If you only deploy one sync server, you just need one certificate with one hostname on it.

For example, if you are planning to deploy one sync server, you will need to request a certificate with the following hostname on it: https://WorkFolders.contoso.com

Getting certificate from a trusted CA

There are many commercial CAs from which you can purchase the certificate from. You can find the CAs trusted by Microsoft on this page: http://support.microsoft.com/kb/931125

To purchase certificate, you need to visit the CA’s website, and follow the instructions on the website. Each CA has a different procedure on certificate purchase.

Testing using Self-signed certificate

For testing, you can also use a self-signed certificate. To generate self-signed certificate, type the following in a Windows PowerShell session:

PS C:\> New-SelfSignedCertificate -DnsName <server dns names> -CertStoreLocation cert:Localmachine\My

For example:

PS C:\> New-SelfSignedCertificate -DnsName “SyncSvr.Contoso.com”,”WorkFolders.Contoso.com” -CertStoreLocation cert:Localmachine\My

Certificates from Enterprise CA

Windows Server Active Directory Certificate Services (AD CS) can issue certificates in a domain environment, you may think of getting the sync server certificate from the AD CS. However, the limitation with certificates issued by AD CS, is that it will not be trusted by the devices which are not domain joined. Work Folders is designed to support BYOD, and it is expected that the devices are not domain joined, therefore user needs to go through some manual steps to trust the Enterprise CA. The instructions are available on this TechNet page: http://technet.microsoft.com/en-us/library/cc750534.aspx.

Installing a certificate

Once you get the certificate, you need to install it on the Work Folders server and the reverse proxy server, since both servers will handle the sync request. Copy the certificate to the Work Folders server and the reverse proxy server, and import the certificate:

PS C:\> Import-PfxCertificate –FilePath <certFile.pfx> -CertStoreLocation cert:LocalMachine\My

Note that, if you are testing with a self-signed certificate on the Work Folder server, you don’t need to import the certificate again. As the self-signed certificate is already been installed on the local server.

Configure SSL certificate binding

To bind the SSL certificate, open an elevated cmdline window (NOT a Windows PowerShell window), and run:

netsh http add sslcert ipport=0.0.0.0:443 certhash=<Cert thumbprint> appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=MY

Note:

• The cmd above will bind the certificate to the root (all hostnames on the server) of the server with port 443.
• You can get the certificate thumbprint by running the following cmdlet:

PS C:\>Get-ChildItem –Path cert:\LocalMachine\My

Testing using self-signed certificate

The steps below are only for testing purposes using the self-signed certificate, because the self-signed certificates are not trusted by client by default. The steps are not necessary if the certificates are purchased from the well-known trusted CAs.

On the server:

1. Exports the self-signed certificates from the server. Run the following cmdlets on the sync server:

PS C:\>$cert = Get-ChildItem –Path cert:\LocalMachine\My\<thumbprint>

PS C:\>Export-Certificate –Cert $cert –Filepath servercert.p7b –Type P7B

Note: you can change the –FilePath parameter input to specify a location you want the certificate to be exported to. You will need to remember the location, so in the next step, you can copy the files to the client devices.

2. Copy the certificate file to the testing client device.

On the client:

3. On the client machine, install the certificates, by right click on the certificate file, and select “Install certificate”.

4. Follow the wizard to install the certificate in the “Trusted Root Certification Authorities”.

5. Complete the installation

Client setup

1. Open the Control Panel -> System and Security->Work Folders
2. Provide the email address for the user (for example U1@contoso.com) Or entering the Url directly if Work Folder discovery is not configured in the deployment.
3. Check the setup completes and client is able to sync files afterwards.

Certificate monitoring

Once the certificate in place, you need to monitor it for cases such as certificate renewal.

This TechNet article provides a good overview and cmdlets to manage certificates:

http://social.technet.microsoft.com/wiki/contents/articles/14250.certificate-services-lifecycle-notifications.aspx

Cluster consideration

Work Folders supports running in failover cluster mode. Below is a quick check list on configuring certificates in clusters:

1. Acquire the certificate, make sure the hostname matches the Work Folder VCO name, not the node name. The VCO name is the virtual Work Folders can be moved to different nodes in a cluster.
2. Import the certificate to all the cluster nodes, as described in Installing certificate section.
3. Bind certificate on each of the cluster nodes, as described in Binding section.
4. Configure certificates notification on each of the cluster nodes, as described in Monitoring section.

If you are deploying multiple VCOs in a cluster, you need to make sure the certificate contains all the VCO hostnames as well as the discovery hostname, or using a wildcard certificate.

For example, in the following setup:

1. 2 node cluster, with N1 and N2 as the machine names.
2. Created 2 VCOs (WF1.contoso.com and WF2.contoso.com) to support work folders.
3. When acquiring certificates, you need to make sure the certificate contains the hostnames: WF1.contoso.com and WF2.contoso.com
4. And the certificate is installed and bind to both nodes of the cluster (machines N1 and N2), and reverse proxy server.

Note: the clustering support is not in the Preview release of Server 2012 R2, please make sure to test clustering with the RTM builds.

Conclusion

The Work Folders server requires SSL certificate for client to connect by default, and is highly recommended for production deployment. I hope this blog post provides you the details on how you can configure and manage the SSL certificates on the Work Folder servers. If you have questions not covered here, please raise it in the comments so that I can address it with upcoming postings.