Client Certificates and Exchange Server

The Microsoft Exchange Team Blog this week featured two very interesting posts: one on an executive-level reorganization (more on that next week), and one on the mechanics of setting up client certificate authentication. Seeing the detailed explanation of how to set up client certificate authentication reminded me that not everyone knows what it is, when it’s useful, or what you have to do to use it. (I’ll leave aside the how-to aspects of the setup, which are well covered in the original blog post).

Client certificate authentication helps solve one of the basic problems of user-level computer security: Passwords aren’t very secure. That’s because human-chosen passwords generally have a low degree of randomness, or entropy. By some measurements, even a 20- or 30-character passphrase might have only about 40 bits worth of entropy, meaning that its effective strength is closer to that of a 5-character password. The bigger problem is that most people don’t use 20- or 30-character passphrases; they choose short, simple strings because they’re easier to remember.

There are many other problems associated with passwords. For example, if you set the password complexity rules for your domain too high, many users will write their passwords down. Users also have the unfortunate habit of using the same passwords for their corporate and personal accounts, meaning that an attacker who cracks a user’s Yahoo! password, for example, could get the bonus of free access to your corporate resources. As a final insult, passwords act as a single authentication factor; anyone who knows the password can impersonate the user.

Client certificates address all of these weaknesses. When you use them for authentication, the basic workflow looks like this:

Step 3 already happens on your computer hundreds of times a day; every time you visit an SSL-secured website, your computer requests, receives, and validates a server SSL certificate. The difference in this case is that the client is also presenting a certificate of its own that the server can check. For this reason, OWA is a natural place to apply certificate authentication. However, Microsoft supports client certificates for a number of other uses, including smartcard-based logon and the Encrypting File System (EFS).

Does the increased security of certificate authentication make up for the increased cost and overhead of issuing and managing certificates for your users? That’s a hard question to answer—and one that has been debated for at least the 15 or so years that client certificates have been widely available. You’ll have to survey your own environment to see what makes the most sense for it, keeping in mind the many other uses for certificates in a Windows environment.