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
No me funciona. Error de SSL.
Testing HTTP GET:
Response: Error en el servidor remoto: (501) Sin implementar.
Inspect the HTTP code given above.
501/505: This is correct behaviour, and means it is responding!
403: The server requires SSL and will not let you connect over HTTP.
401: Wrong username/password. May also occur if you’re using a reverse proxy which performs authentication.
Great article!
Quick question: Can I have some EAS clients authenticate with username/password only (no certs) and have others just use client certificates (no passwords)?
It sounds like that flexibility would be possible if “accept client certificates” is chosen as well as having “basic authentication” ticked. However your post above seems to indicate that it’s an all-or-nothing thing.
I’d really like to have clients pick whichever auth method they’d prefer, so hopefully it’s possible!
What you want is one of the common challenges holding back client certificate authentication scenarios. Sure, works with Windows Mobile, but what about Android, etc?
If the devices connect directly to Exchange I am not aware of a good solution for doing this. I can think of some hackish approaches that I haven’t tested, but by default it’s all or nothing. (If someone with deeper knowledge of IIS knows something I don’t feel free to correct me.)
If you are using ForeFront TMG or a similar solution you can handle it. With TMG the authentication is performed at the edge, and delegated to the Exchange Server. By using the “Fallback” option in the web listener the server will first ask the client if it’s able to provide a client certificate, and if it isn’t able to do this it can fall back to basic authentication instead. So if you have a TMG server it’s not so much work to implement, if you’re just using a basic firewall in front of Exchange it might not be worth the effort trying to make it work.
Great, thanks so much for the reply Andreas! Much appreciated.
I was looking forward to following your guidance but it seems I’m a few steps behind. For client certificates, I wanted to create self-signed certs. I attempted using OpenSSL For Windows, mostly following the info at http://serverfault.com/questions/168580/creating-client-certificates but when it came to step 6 to sign the client certificates “with the CA cert” I never have gotten the openssl.cfg file right do get it to open the ca.key.
Can you refer me to better guides to create certs for mobile devices or do you have any comments that might provide guidance so I can get to the point of testing with your emulator program?
Thanks.
I did finally get the certs created as outlined in the article I referenced earlier, but I’m not sure I know how to import/enroll them.
The documentation to which one is referred for client certificate mapping authentication says that for using AD authentication, both the server and client have to be members of an Active Directory domain. For the testing that might work, but the mobile devices are not going to be members of the/a domain. Is this an issue with client certificate mapping authentication using Active Directory?
The client in the case of the mobile devices is the TMG server, or a similar solution. The certificate is what proves the identity of the mobile device, but TMG needs to be a member of Active Directory to use Kerberos Constrained Delegation.
There are differences between the mobile operating systems as to what format they like their certificates in, but both Windows Mobile and iPhone are happy to use pfx files whereas Android prefers it as a p12 (which can be just a renamed pfx file if you like). The details of how to import them and use them is also slightly out of scope for this article – as I’ve said before in a number of articles. You will need to do testing before using client certificates, but once you get it working it’s real nice
Couldn’t get it working until I ran the following commands:
appcmd unlock config /section:clientCertificateMappingAuthentication
appcmd set config “Default Web Site/Microsoft-Server-ActiveSync” -section:clientCertificateMappingAuthentication /enabled:true
I kept getting 401.2.
I’m using Moxier Mail on Android which does support client certificates as well as S/MIME signing and encryption.
It could be that your server is more tightened security-wise than my lab environment
But of course in a production environment one should be doing so, so it’s a useful tip (will insert it into the article).
Haven’t gotten round to testing Moxier – I usually prefer to not having to resort to third-party utils/sw for what I consider basic functionality. (In my opinion the lack of proper Exchange support on Android is something Google should be ashamed of.)
But unless S/MIME & client certs support shows up in the Samsung Galaxy S II (I mean – the Gingerbread ROM for the S is promising) I’ll eventually have to test Moxier or TouchDown properly.
I keep getting this error using the utility. I have SSL and certificate both checked. But all iPhones and iPads are ok. Is it normal?
Testing HTTP GET:
Response: The remote server returned an error: (403) Forbidden.
Explanation:
The server requires SSL and will not let you connect over HTTP.
(For instance trying to connect over HTTP while IIS requires SSL.)
Status: Further action required
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Testing HTTP OPTIONS:
Response: The remote server returned an error: (403) Forbidden.
Explanation:
The server requires SSL and will not let you connect over HTTP.
(For instance trying to connect over HTTP while IIS requires SSL.)
Status: Further action required
If iOS devices are working your ActiveSync setup should be good in general – does the 403 error only occur with my utility or also with Android devices (if you are able to test this)? The 403 error indicates that for some reason you aren’t allowed to use the service, even though it’s most likely up-and-running. Do you know if the Exchange Server is running any kind of filters as to which devices are allowed? Or does it require client certificates perhaps? A reverse proxy in front performing additional checks?
Is this Exchange 2007 or 2010?
Thanks for your response Andreas. The 403 error occurs on your utility and Android devices. The Android devices would work only if the Exchange 2010 is set to “ignore client certificate”. There’s also no rules to govern which device can log on. We even allow non-provisioned devices.
A client certificate is needed but I’ve tried the certificate on the utility and android without any success.
I don’t know what else to check.
Well, ok, then the 403 would indeed be caused by failing client certificate authentication.
I have tested my utility quite extensively against both Exchange 2007 and 2010 with and without a ForeFront TMG in front. Do you have the client cert as a pfx file with a private key? And password protected? Does my utility give any errors indicating it’s not able to read the certificate? (I assume you are using the latest version of EAS MD.) Is your Exchange server configured to require both username/password and a client cert, or only certificates? Is the username in user@domain.com or domain\user format?
iOS devices have good support for client certs so they usully work nicely once they’re configured. Android can be a hassle with client certs (as they’re not supported in the native EAS client). Are you using a third-party ActiveSync client? TouchDown from Nitrodesk supports it, and the newer Samsung support it (you don’t get to configure it without MDM though). Ice Cream Sandwich should bring native support for client certs. So I can’t really tell why it’s failing on your Android devices without knowing more.
As for why it doesn’t work with my utility..that’s on my table
Try to remove the fake device from OWA (if it’s present) and re-attempt to sync.