Certificates is not only a recurring theme on this site, it’s also a recurring pain point from what I hear. Getting it working is just down right confusing sometimes. With this in mind I thought I’d walk us through a scenario where you want to secure your Exchange ActiveSync deployment with the use of client certificates.

Ok, I said “a scenario”, but it might be more correct to say “a couple of scenarios” because there are a couple of design choices you can make. But let’s set the stage before we proceed – why are we even discussing certificates in the first place? What are they good for?

Let’s be honest – you will save yourself a lot of work and hassle if you go for the good old username & password combo. But through using certificates you can achieve other goals which might not be met the same way without taking the route of yet more complex configurations:
- Security
- User friendliness

Yes, these are normally two conflicting goals – I know Security can be beefed up with certificates as a means of adding an extra factor to the authentication process, as something you need in addition to a password. User friendliness can be improved upon by removing the need for users typing in complex passwords every couple of weeks on their mobile device.

With that in mind let’s see what we can do to get this train rolling. Oh, yes, one more word of advice; since we are dealing with mobile devices do not hit the implement switch before you have checked out if there are any devices that are not able to handle it. Windows Mobile devices are ok, iPhones are ok, possibly Symbian too. Don’t know about Android (it would be specific to the ActiveSync client used since it’s not provided by the OS). “Feature phones”, also known colloquially as “dumbphones” are probably out of the loop.

I assume that you have already installed an Exchange Server with the Client Access Server role functioning before following along here. I am using Exchange Server 2010 RTM on Windows Server 2008 R2, and ForeFront TMG 2010 as a firewall/reverse proxy. Exchange 2007 might be slightly different on some points, but pretty similar. Which OS you’re running matters because part of the functionality is provided by the OS, so if you’re running on Windows Server 2003 things will also differ from what I do on my servers.

We’ll start out enabling client certificate authentication directly on the Exchange server assuming for the sake of the test that all mobile devices connect via the LAN In the Exchange Management Console go to
Server Configuration->Client Access->Exchange ActiveSync.
Your properties might look like this:

You’ll want to switch this to “Require client certificates” like so:
 

Note that we have unchecked “Basic authentication” as well.
As it says in the dialog box you need to configure SSL itself through the IIS manager. Often when I test and debug in my lab I disable SSL and run it through plain HTTP. This will not work if you want to use client certificates, and you should require SSL. (If you haven’t messed around with this setting the defaults after installing Exchange 2010 are already configured to require SSL.)

Actually you could change the client certificate requirement in IIS too:

And as long as we have the IIS console open. How about we configure the certificate mapping at the same time? Mapping what you say? While having a certificate is a nice thing in itself how does Exchange verify if your certificate is good? If someone presented you with a hand-written post-it note with a doodled self portrait and “driver’s license” written along the top would you trust it? Wouldn’t you rather have the laminated, (or credit card version), with some official looking logos and stamps? We need to define where Exchange should perform the lookup for verifying that your certificate is good, and this we call mapping the certificate. Rather than explain the process in detail I’ll refer you to this link for the necessary steps:
http://www.iis.net/ConfigReference/…/…/…/clientCertificateMappingAuthentication

Short version – install the “Client Certificate Mapping Authentication” role service, and enable it to have Exchange use Active Directory as the source for certificate verification.

Since we haven’t gotten to the part of enrolling certificates on devices yet you can use my ActiveSync “emulator” if you’d like to test at this point – http://mobilitydojo.net/downloads

If all is good you should be able to run a “Basic Connectivity Test” even without specifying a password. (You need to provide the username as that’s used for other purposes behind the scenes.) The .cer file I’m using is a certificate I have enrolled through AD directly to the “Personal” store on my development box, and exported to a file without a private key.

Now, back to that “Basic authentication” bit again. I said there might be different scenarios to choose from, and technically you don’t have to uncheck the box like I did. You have three possible combinations of client certificates and basic authentication;
- Basic authentication enabled, ignore/accept client certificates. This is the default. Will let you synchronize as long as you provide a valid username and password.
- Basic authentication disabled, require client certificate. Will let you synchronize as long as you provide a valid certificate.
- Basic authentication enabled, require client certificate. Will let you synchronize provided you supply both a valid certificate, and a username & password combo.

You can test out all combos with a device, and/or my utility, but I’m getting differing results testing in a browser. (Which is not the recommended way to test EAS anyways.) Pick your poison as to whether you’d like to use a real device or my utility but at this point it’s easier to ignore real devices and get back to those later. What this means is that whether you enable or disable basic authentication, (in addition to requiring certificates of course), dictates whether you require one or two factors for authenticating the users. You’ll see the 401 and 403 error codes when testing if you don’t get the authentication right.

I guess we’re doing fine so far aren’t we? But so far we have concerned ourselves with the easy part of the equation. Play around with the settings and see if you can make it work, and in the next installment I’ll have a crack at making it all work from outside your LAN