First published on TECHNET on Aug 09, 2013
In the last blog
, I’ve provided the step by step guide to deploy Work Folders in a test lab environment, where the client is using an unsecure connection 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.
You will need the following setup:
Work Folders server set up and configured with at least one sync share. (Let’s name it as
One client device running Windows 7 or later
How Work Folders uses certificate?
The Work Folder client server communication is built using secure HTTP 1.1. According to
“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
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:
: That the current date and time is within the "Valid from" and "Valid to" date range on the certificate.
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:
The number of sync servers you are deploying.
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
, 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.
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.
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:
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:
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:
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:
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.
1. Export the self-signed certificates from the server. Run the following cmdlets on the sync server:
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.
3. On the client machine, install the certificates, by right click on the certificate file, and select “
4. Follow the wizard to install the certificate in the “
Trusted Root Certification Authorities
5. Complete the installation
Control Panel -> System and Security->Work Folders
Provide the email address for the user (for example
) or enter the Url directly if Work Folder discovery is not configured in the deployment.
Check the setup completes and client is able to sync files afterwards.
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:
Bind certificate on each of the cluster nodes, as described in
Configure certificates notification on each of the cluster nodes, as described in
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:
2 node cluster, with N1 and N2 as the machine names.
Created 2 VCOs (WF1.contoso.com and WF2.contoso.com) to support work folders.
When acquiring certificates, you need to make sure the certificate contains the hostnames: WF1.contoso.com and WF2.contoso.com
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.
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.