Designing and Implementing Mobility in Exchange Server 2010: Securing Access to ActiveSync with Secure Sockets Layer Encryption

2/22/2011 9:04:15 AM
By default, ActiveSync 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, which is where most mobile devices originate from.

Because of this limitation, a form of authentication that can be sent across the Internet must be used. This effectively limits the ActiveSync 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, mail messages and other confidential information are transmitted in clear text, which is 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 an https:// uses them, and the entire online merchant community is dependent upon the security of the system.

For ActiveSync, 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 ActiveSync (and other Exchange HTTP access methods such as OWA) 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 certificate authority— Another common approach is to install and configure Windows Server 2003/2008 Certificate Services 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 or mobile devices will recognize the CA, and error messages to that effect will be encountered on the devices unless the certificates are trusted.

Each of these options is outlined in the subsequent sections of this chapter.

Installing a Third-Party CA on a CAS

If a third-party certificate authority will be used to enable SSL on a server with the CAS role, a certificate request must first be generated directly from the CAS. After this request has been generated, it can be sent to the third-party CA, who will then verify the identity of the organization and send it back, where it can be installed on the server.

When deciding which CA to use, keep in mind that Windows Mobile devices automatically trust the certificate authorities of the following organizations:

  • VeriSign

  • Thawte

  • GTE CyberTrust

  • GlobalSign

  • RSA

  • Equifax

  • Entrust.net

  • Valicert (Windows Mobile 5.0 and up only)

If an internal CA will be utilized, this section and its procedures can be skipped, and you can proceed directly to the subsequent section titled “Using an Internal Certificate Authority for OWA Certificates.”

To generate an SSL certificate request for use with a third-party CA, you can create a certificate from the Exchange Management Shell using the New-ExchangeCertificate applet, or you can create the request directly from IIS. For optimal flexibility, use the PowerShell applet because it enables you to create multiple Subject Alternative Name (SAN) entries in the certificate, enabling the Exchange server to impersonate multiple FQDNs, such as mail.companyabc.com, autodiscover.companyabc.com, activesync.companyabc.com, and so on.

After the certificate request has been generated, the text file, which will look similar to the one shown in Figure 1, can then be emailed or otherwise transmitted to the certificate authority via their individual process. Each CA has a different procedure, and the exact steps need to follow the individual CA’s process. After an organization’s identity has been proven by the CA, they will send back the server certificate, typically in the form of a file, or as part of the body of an email message.

Figure 1. Viewing a certificate request file.

The certificate then needs to be installed on the server itself. If it was sent in the form of a .cer file, it can simply be imported via the process described next. If it was included in the body of an email, the certificate itself needs to be cut and pasted into a text editor such as Notepad and saved as a .cer file. After the .cer file has been obtained, it can be installed on the CAS using the Import-ExchangeCertificate applet.

Using an Internal Certificate Authority for OWA Certificates

If a third-party certificate authority is not utilized, an internal CA can be set up instead. There are several different CA options, including several third-party products, and it might be beneficial to take advantage of an existing internal CA. Windows Server 2008 also has a very functional CA solution built into the product, and one can be installed into an organization.


Proper design of a secure PKI is a complex subject, and organizations might want to spend a good amount of time examining the many factors that can influence CA design. This sample scenario assumes a very basic design, with an enterprise CA installed directly into a domain. Most enterprise CAs want to consider a stand-alone root CA and a second or even third tier of intermediate and issuing enterprise CAs, depending on the organization.

The following types of CAs are available for installation:

  • Enterprise Root CA— An enterprise root CA is the highest level CA for an organization. By default, all members of the forest where it is installed trust it, which can make it a convenient mechanism for securing OWA or other services within a domain environment. Unless an existing enterprise root CA is in place, this is the typical choice for a homegrown CA solution in an organization.

  • Enterprise Subordinate CA— An enterprise subordinate CA is subordinate to an existing enterprise root CA, and must receive a certificate from that root CA to work properly. In certain large organizations, it might be useful to have a hierarchy of CAs, or the desire might exist to isolate the CA structure for OWA to a subordinate enterprise CA structure.

  • Stand-Alone Root CA— A stand-alone root CA is similar to an enterprise root CA, in that it provides for its own unique identity, and can be uniquely configured. It differs from an enterprise root CA in that it is not automatically trusted by any forest clients in an organization.

  • Stand-Alone Subordinate CA— A stand-alone subordinate CA is similar to an enterprise subordinate CA, except that it is not directly tied or trusted by the forest structure, and must take its own certificate from a stand-alone root CA.

After the internal CA is in place, the CAS can automatically use it for generation of certificates.

After being placed on a server, SSL encryption will be made available on the CAS. If the enterprise CA was installed in an Active Directory domain, all the domain members will include the internal CA as a trusted root authority and connect to OWA via SSL with no errors. External or nondomain members, however, will need to install the enterprise CA into their local trusted root authorities. This includes Windows Mobile devices as well. The procedure for installing a third-party certificate for a Windows Mobile device is covered in the next section of this chapter titled “Installing a Root Certificate on a Windows Mobile Device.”

Installing a Root Certificate on a Windows Mobile Device

If a third-party or self-generated certificate authority is used for ActiveSync, Windows Mobile devices must be configured to trust that CA. If they are not configured like this, they will error out with something similar to the error shown in Figure 2 when attempting to connect via ActiveSync.

Figure 2. Error received when Windows Mobile device does not trust the root of the CA.

For Windows desktops and laptops, this task is relatively straightforward, and involves simply installing the enterprise root CA for this third-party certificate into the Trusted Root Certificate Authority group for the machine.


Be sure to select the root certificate, and not the actual certificate used for the virtual server

For Windows Mobile devices, however, the enterprise root certificate must first be exported to a .cer file. After the certificate has been exported, it must be copied to the Windows Mobile device, either through the Explore button in Microsoft ActiveSync (while the device is cradled), or via a memory chip.

After the .cer file is installed, clicking on it using the File Explorer in Windows Mobile (Start, Programs, File Explorer) invokes a dialog box, warning that you are about to install the certificate. Click Yes and the certificate will be automatically installed and ActiveSync over SSL can be performed.

  •  Enabling ActiveSync in Exchange Server 2010
  •  Understanding Mobility Enhancements in Exchange Server 2010
  •  Monitoring a SharePoint 2010 Environment : Using the SharePoint Health Analyzer
  •  Using SharePoint 2010 Management PowerShell for Backup and Restore
  •  Restoring SharePoint Using SharePoint Central Administration
  •  Windows Azure : Static reference data (part 2) - Performance disadvantages of a chatty interface & Caching static data
  •  Windows Azure : Static reference data (part 1) - Representing simple static data in SQL Azure & Representing simple static data in the Table service
  •  Performing Granular Backup Using the SharePoint Central Administration
  •  Using SharePoint Central Administration for Backup and Restore
  •  Backing Up and Restoring a SharePoint Environment : Using the Recycle Bin for Recovery
  •  Using Non-Windows Systems to Access Exchange Server 2010 : Understanding Other Non-Windows Client Access Methods
  •  Using Non-Windows Systems to Access Exchange Server 2010 : Remote Desktop Connection Client for Mac
  •  Using Non-Windows Systems to Access Exchange Server 2010 : Configuring and Implementing Entourage for the Mac
  •  Using Non-Windows Systems to Access Exchange Server 2010 : Mac Mail, iCal, and Address Book
  •  Parallel Programming with Microsoft .Net : Futures - Variations
  •  Parallel Programming with Microsoft .Net : Futures - Example: The Adatum Financial Dashboard
  •  Parallel Programming with Microsoft .Net : Futures - The Basics
  •  Using Non-Windows Systems to Access Exchange Server 2010 : Outlook Express
  •  Using Non-Windows Systems to Access Exchange Server 2010 : Understanding Non-Windows–Based Mail Client Options
  •  Deploying the Client for Microsoft Exchange Server 2010 : Deploying with Microsoft System Center Configuration Manager 2007
    Top 10
    Apple iPhone 5 - The World’s Best Smartphone? (Part 2)
    Apple iPhone 5 - The World’s Best Smartphone? (Part 1)
    Essential Stuffs For Your Tablet
    Experience The Powerful And Classic LG Optimus LTE II
    HTC Desire C - Does It Have Anything Good?
    Ipad Rumour Mill Jumps Shark
    LG Optimus 3D Max Review (Part 2)
    LG Optimus 3D Max Review (Part 1)
    LG Optimus L3 E400 Review (Part 2)
    LG Optimus L3 E400 Review (Part 1)
    Most View
    Transact-SQL in SQL Server 2008 : Spatial Data Types (part 2) - Working with Geography Data
    7 Necessary Accessories For DSLR
    Tools for the job (Part 4) - Anatomy of a live CD
    Wireless Networking Essentials (Part 2) : Wireless Repeater, Limitation Of A Wireless Network
    Bang & Olufsen Beolit 12 – High-end pick-i-nick baskets
    Network Programming with Windows Sockets : A Thread-Safe DLL for Socket Messages
    The Second BlackBerry Developers Conference Asia (Part 1)
    Building a WPF Application without XAML (part 1)
    High Availability in Exchange Server 2010 : Exchange Server database technologies
    Upgrade Website With Mysql On Linux (Part 1) - Access MySQL from PHP
    SteelSeries Diablo III Mouse - Demon Hunting Weapon of Choice
    The HP Virtual Server Environment : Virtual Partitions (Peak Performance Virtualization)
    3D Printing … for people who don’t have a 3D printer
    Monitoring a SharePoint 2010 Environment : Understanding Timer Jobs for SharePoint 2010
    SQL Server 2008 Instance Architecture
    Windows 7 : Burning Your Pictures to CD or DVD
    a-Jays Four
    Tablet Toshiba AT200 - The World’s Thinnest Tablet
    Richard Cobbett: Publish and be damned