Exchange Server and Outlook have supported Secure MIME (S/MIME) for a while now, and more and more Exchange customers are demanding to know how to set up and use S/MIME in their environments. The process isn't trivial and is too involved for one column, but I can give you some pointers.
First, download and read Microsoft's excellent new article "Quick Start for SMIME in Exchange Server 2003" (see the Resources section of this UPDATE for details). You can easily read and absorb this 40-page guide in an afternoon. The guide provides a road map for setting up an S/MIME test lab and using it to gain experience with Windows Certificate Services tools and Exchange and to test S/MIME deployment.
Second, think about why and how you want to use S/MIME. The component protocols that S/MIME supports let your clients digitally sign messages, thus preventing attackers from tampering with those messages. The protocols also let clients encrypt messages so that only the intended recipients can read the messages. Both these abilities are useful, but just how useful are they to your organization? Most companies that want to deploy S/MIME do so for one of three reasons:
- Companies want to use digital signatures for nonrepudiation when dealing with partners, customers, and suppliers. These companies want a way to prove that a message was sent by a particular person and that the contents weren't altered. Nonrepudiation provides protection against weaseling (e.g., a supplier denying that an agreement was reached on a price).
- Companies want to be able to authenticate messages that relate to crucial functions—-usually involving money. Travel requests, purchase orders, and the like are great candidates for authentication with signature-based applications because the signatures can't be faked easily.
- Companies want to encrypt some messages for protection against eavesdropping or compromise. Because S/MIME encrypts messages before they're sent, the messages remain encrypted on the server, providing security against untrustworthy administrators as well as attackers.
To get S/MIME running in your environment, you'll need to take the following steps:
- Set up a Certificate Authority (CA) that can issue certificates to users. Third-party CAs such as VeriSign sell (expensive) end-user certificates, or you can use Windows Server 2003 or Windows 2000 Certificate Services to issue your own certificates. This process involves some subtleties (namely, if someone compromises your CA, they effectively compromise every certificate the CA ever issued), so it's best to set up a CA in a test lab first and carefully review the CA documentation to be sure you understand it before applying this step in production.
- Get the right version of Exchange. Exchange Server 5.5 and later support S/MIME. Exchange 2000 Server and Exchange 5.5 use a service called the Key Management Server (KMS), which interacts with the Windows Certificate Services component to handle certificate issuance, rekeying, and revocation. Exchange 2003 doesn't use the KMS; instead, it depends on the Windows 2003 Certificate Services component, which offers several improvements over its predecessors. No matter which Exchange version you use, you need to go to the Mailbox Store Properties dialog box's General tab and specify that clients can use S/MIME signatures.
- Provide certificates for users. If you use the KMS, users can directly enroll through Outlook 2000 (and later); you can also let users get certificates through the Windows Certificate Services Web enrollment tool. You can even set up automatic enrollment so that each user automatically gets a certificate.
- Use Outlook's Tools, Options settings' Security tab to configure Outlook to use the certificates. Each user must tell Outlook which certificate to use. (As a bonus, depending on how you configure your CA, the certificates you issue might be usable for other purposes, including Encrypting File System--EFS--and Authenticode code-signing for Microsoft Office macros.)
- Teach your users how to sign and encrypt messages. This step might be the easiest one because Outlook has simple toolbar buttons for signing and encrypting messages. If you prefer, you can use a Group Policy setting to force signing or encrypting to always occur.
Using S/MIME raises some business questions. Should all users be able to send encrypted messages to each other? Should users be able to send encrypted email outside the company? Who should sign messages, and under what circumstances? Dealing with these questions is one part of S/MIME deployment that you must figure out on your own, but the security-related benefits of doing so are likely to be worth the time.