Implementing an Exchange 2003-Based Message Security System in a Test Environment
A Microsoft® Exchange Server 2003-based message security system is made up of several different technologies with many options as to what specific products are used to implement those technologies.
The benefit of this flexibility is that Exchange customers can deploy message security systems that more closely meet their business requirements than with a single, monolithic solution. The disadvantage, however, is that the number of possible configurations that can make up an Exchange Server 2003-based message security system makes it impossible to provide all the information required to deploy a system in a single document. Instead, administrators have to combine information relevant to each of the components that make up the system to form the complete picture. As a result, to administrators learning about Secure/Multipurpose Internet Mail Extensions (S/MIME), there is no source about how all the components should fit together and provide a high-level understanding of the message security system.
Being able to assemble a functional message security system is an important part of learning about S/MIME. But the flexibility that enables customized S/MIME solutions can be a hindrance to learning about S/MIME. Because each S/MIME implementation is different, it is impossible to give information on how to build a fully functional S/MIME system that is accurate for meeting specific requirements.
It is possible to provide guidance on how to build a message security system suitable for a test environment. Because a test environment has limited requirements, this narrow scope makes it possible to present a limited number of options. Administrators who want to assemble an S/MIME system for learning purposes can build a fully functional test system by following this information. This test system can be used to further the skills and knowledge needed to deploy a full system in production from the relevant sources of information.
This section provides a "getting started" point for Exchange administrators in deploying a fully functional S/MIME system in a lab environment using technologies from Microsoft. After following this section, Exchange administrators will have a fully functional S/MIME environment based on Certificate Services, Exchange 2003, Internet Explorer 6 with the S/MIME control, Outlook Express 6, and Microsoft Office Outlook® 2003. In this lab environment, Exchange administrators will see how the different technologies work together to provide the complete S/MIME system.
Because this section is intended only to help with the deployment of a test lab environment, the following practices should be noted as appropriate only for test environments:
SSL encryption The configuration described in this section does not use Secure Sockets Layer (SSL) encryption for HTTP, Post Office Protocol version 3 (POP3), or Internet Message Access Protocol version 4rev1 (IMAP4) access. Although this configuration may be appropriate for a test lab, SSL encryption should be used with these protocols in a production environment. For information about how to configure these protocols to use SSL, see Exchange Server 2003 Help.
Enterprise Root certification authority This section uses an Enterprise Root certification authority (CA) to issue S/MIME certificates rather than developing a broader CA hierarchy. Although this approach simplifies the deployment of digital certificates, this practice is not recommended for production environments. A successful Microsoft Windows certification infrastructure requires planning beyond the scope of this section. For information about how to plan and deploy a public key infrastructure (PKI) hierarchy, see "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure."
Digital certificate requirements This section provides instructions about how to manually obtain S/MIME digital certificates by using the default certificate templates in Windows Server™ 2003 certification authority. In a production environment, it is preferable to use certificate autoenrollment, because this is easier for users. In addition, the default certificates do not use features such as strong key protection, which is a requirement for many organizations. In a production environment, you may want to configure certificate templates to conform to your organization's security requirements. For information about autoenrollment, see "Certificate Autoenrollment in Windows Server 2003." For information about configuring certificate templates, see "Implementing and Administering Certificate Templates in Windows Server 2003."