by Dan Sullivan

Further Considerations for Using SSL Certificates with Microsoft Exchange Server

Enterprise Microsoft Exchange deployments can require a somewhat complex architecture. The reason is that Microsoft Exchange has been designed to maintain adequate performance levels while scaling to a large user base. The common way to deal with the need for scalability (as well as reliability) is to distribute the workload over multiple servers. In the case of Microsoft Exchange, distribution of workload has been organized around several roles that can be run on different servers:

• Mailbox role for managing mailboxes, folders, and calendars
• Client access role for supporting Outlook Web Access, Microsoft ActiveSync, Outlook Anywhere, and some email-related protocols
• Hub transport role supporting message transport, journaling, and some security services
• Edge server role for routing external traffic; supports some security services
• Unified messaging role for integrating email with voice and fax services

While supporting scalability, the option of running role services on multiple services can add to system management overhead. Of particular importance to this discussion are the implications for SSL-secured communications. Fortunately, a specialized type of SSL certificate, known as a Subject Alternative Name (SAN) SSL certificate can help reduce some of the management overhead.

A SAN SSL is designed to support multiple servers using a single certificate. The basic idea behind a SAN SSL certificate is that multiple servers can be listed in a single certificate. For example, if your Microsoft Exchange deployment requires several servers, say one for each of the five roles listed earlier, you could secure these with five separate SSL certificates or with a single SAN SSL certificate.

Most of the major browsers in use today, including Internet Explorer, Mozilla Firefox, Opera, and Apple Safari, support SAN SSL certificates. When the browser is working with an SSL-based connection, it can authenticate a server in a few ways:

• The host name of the server is the same as the common name in the SSL certificate
• A wildcard pattern, such as *.domainname.com, matches the common name in the SSL certificate
• The host name of the server matches one of the host names listed in the Subject Alternative Name field in the SSL certificate

SAN SSL certificates work well in the Microsoft Exchange environment and Microsoft recommends their use as a best practice. A potential problem with SAN SSLs is that you forget to include one or more of the server names in the CSR. Fortunately, the CSR wizard in Microsoft Exchange 2010 is designed to help avoid this problem by collecting information about which services you want to include in the certificate. It uses this information to make sure all the needed servers are included in the CSR.

Next, we will consider a similar process for installing SSL certificates in SharePoint servers.

<< Part 3 | Part 5 >>

About the Author

Dan Sullivan has more than 20 years of IT experience that includes engagements in application design, systems architecture, and enterprise security. His experience includes a broad range of industries, including financial services, manufacturing, government, retail, gas and oil production, power generation, life sciences, and education. Dan has written and presented extensively about systems architecture, infrastructure management, and aligning business and IT strategies. His articles have appeared in Intelligent Enterprise, Business Security Advisor, DM Review, and E-Business Advisor. He has written several books including The Shortcut Guide to Prioritizing Security Spending,The Definitive Guide to Security Management; The Definitive Guide to Information Theft Prevention; The Definitive Guide to Service Oriented Systems Management; The Definitive Guide to Controlling Malware, Spyware, Phishing, and Spam; The Tips and Tricks Guide to Secure Content Appliances; and The Shortcut Guide to Protecting Business Internet Usage.