This is the second post in my series,
How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click
here. In this phase, we will create a new certificate server and generate the user certificate that will be used for ActiveSync authentication. This single certificate will be installed on iPhones and published in Active Directory.
If your organization already has a certificate server, you can use it to create a user certificate, as specified later in this article. In this soup-to-nuts series I will explain how to create a new stand-alone Windows Server 2008 R2 CA (Certification Authority) for this purpose.
Build a Windows 2008 R2 Certificate Server
Begin configuring the Windows Server 2008 R2 server by installing the Active Directory Certificate Services role. This can be a new, single-purpose server or one already deployed in your organization. Contrary to the role name, this is the role to install even if the server is not a member of an Active Directory domain (a workgroup server). Select the following Role Services when installing the ADCS role:
- Certification Authority
- Certification Authority Web Enrollment (this will also install Web Server (IIS) and all necessary components)
If the server is a member of a domain, you can choose whether to install the CA as an Enterprise or Standalone (non-domain based) CA. For our purposes, it really doesn't matter which one you choose. However, if you're planning out a full PKI (which I highly recommend) you should select the CA type that's appropriate for your organization. For this article, we'll make it a standalone Root CA.
Create a new private key and use the default cryptographic service provider (CSP) and key length (2048). Supply a common name for the CA, such as W2K8R2-CA. Note that the default validity period for certificates generated by a Windows Server 2008 R2 CA is 5 years. Set this value for as long as you'd like. Consider the fact that the certificate will have to be replaced on the iPhone and in AD when it expires. I set my validity to 10 years.
Continue through the Add Roles Wizard, accepting all the default settings. Note that the name and domain settings of the server cannot be changed after Certification Authority has been installed. Click Install to complete the installation. No reboot is required, but it is recommended that you run a Windows Update to ensure that the binaries are up to date.
Configure the Certification Authority to Use SSL
In order to request certificates using the web interface, you must enable SSL on the CA's web server. Open
Internet Information Services (IIS) Manager in Administrative Tools. Select the server name and open the
Server Certificates feature. Select
Create Self-Signed Certificate in the Actions pane and supply a friendly name for the certificate, such as "
CA Server".
Next, expand
Sites and select the
Default Web Site. Click
Bindings in the Actions pane and add
HTTPS, using the new self-signed certificate, as shown below.
Now select the CertSrv virtual directory under Default Web Site and open the SSL Settings feature. Select Require SSL and click Apply.
A Word About Certificate Revocation
Certificates can be revoked by the CA Administrator. When the certificate is revoked, it can no longer be used for its intended purpose. A revoked certificate is added to the Certificate Revocation List (CRL) which is usually hosted on the CA server.
Important - When ActiveSync uses client certificates, Exchange ActiveSync 2007/2010
requires confirmation from the CA that the user certificate has not been revoked. This happens before Basic authentication is attempted.
If the CRL is not available, ActiveSync will assume that the certificate has been revoked and the user will not be able to use ActiveSync. You must ensure the CRL (typically, the CA server) is always online and available. For this reason, I recommend virtualizing the CA to provide greater flexibility.
Unless you configure the Online Responder role service which uses the Online Certificate Status Protocol (OCSP), the CA will use a Certificate Revocation List (CRL) to obtain the revocation status of the X.509 user certificate.
OCSP has replaced the traditional CRL file used in the past. It performs much better and has a lower network cost. Complete details about OCSP can be read
here. For the purposes of this article (and brevity), we'll be using a CRL, which requires no further configuration.
Generate a User Certificate
Now we are ready to generate a user certificate from the certificate server. This is a two-step process where a request is submitted and then approved, creating the certificate and its private key.
Requesting the User Certificate
You make the certificate request using Internet Explorer directly from the CA. Go to
https://servername/certsrv and click
Request a certificate.
Click Advanced certificate request and then Create and submit a request to this CA. Click Yes to the Web Access Confirmation warning to allow the website to perform a digital certificate operation on your behalf. Complete the certificate request as shown, using your organization's information.
Note: Some reverse proxy servers and firewalls do not allow spaces or special characters in the certificate name or friendly name. For this reason, I recommend using a simple short name for the user certificate to prevent problems.
Once you submit the certificate request, it must be issued by the CA administrator (probably you). To issue the certificate, expand the Active Directory Certificate Services role in Server Manager > CA server name > Pending Requests. Right-click the pending request ID and select All Tasks > Issue to issue the certificate.
Now you need to install the new user certificate using the ADCS website. Click View the status of a pending certificate request from the Home page and then click the certificate request you generated earlier, as shown below.
Click Yes to the Web Access Confirmation warning to allow the website to perform a digital certificate operation on your behalf and then click Install this certificate.
The user certificate and private key will be installed in the user's (your) Personal certificates store. It now needs to be exported, both with and without the private key. The certificate with the private key will be imported into the iPhone and the other will be published to the user account in Active Directory.
Exporting the Certificates
In Internet Explorer, click Tools > Internet Options > Content > Certificates. You will see the new user certificate in your Personal certificate store. Select the certificate and click Export. Follow the default settings in the Certificate Export Wizard, but make sure you select Yes, export the private key and Include all certificates in the certification path if possible. Supply a password for the certificate. You will need this password to import the certificate for other Mobile Messaging Administrators in the future. Browse to the folder of your choice and name the file ActiveSyncUser.pfx.
Now export the user certificate again, this time choosing No, do not export the private key. Browse to the folder of your choice and name the file ActiveSyncUser.cer. This certificate will be published later to the ActiveSync user accounts in Active Directory.
Lastly, we need to export the CA's root certificate. This will be imported into the Trusted Root Certification Authorities certificate store on the Exchange CAS servers so they can trust the user certificate, since it's self-signed. Click the Intermediate Certification Authorities tab and select the CA's certificate, as shown below.
Click Export and follow the Certificate Export Wizard, selecting all the defaults. Browse to the folder of your choice and name the file RootCA.cer.
We now have a working CA server, a user certificate with and without the private key, and the Root CA certificate.
This concludes Phase 1 of my series,
How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise - Phase 1 - Building the CA. The next phase will cover how to configure the Exchange Client Access Servers for ActiveSync using client certificates.
Other articles in this series:
