The Case for Commercial SSL Certificates for Exchange Server 2007/2010

Businesses who are implementing Microsoft Exchange Server face important decisions about how they will manage SSL certificates.

In the history of Exchange Server there was a time when SSL certificates were optional, but not required by default. Even today there are people who do not consider them mandatory.

The use of SSL certificates with Exchange Server rose to importance as more Exchange services became open to the internet. Services such as Outlook Web Access (now Outlook Web App) for webmail, ActiveSync for mobile devices, Outlook Anywhere, and the new Exchange Web Services APIs are now web-facing and play a critical role in business communications.

Exchange Server 2007 was the first version to require SSL certificates by default for certain services. It was also the first time many Exchange administrators had encountered SAN certificates.

SAN stands for “Subject Alternative Names” and refers to using additional attributes in the SSL certificate to list more than one name for the SSL certificate. This became necessary with the move to SSL by default for Exchange Server 2007, because the server would now be answering to more than one name for SSL connections. This typically includes:

• The server’s fully qualified domain name
• One or more public aliases such as “mail.domain.com” or “webmail.domain.com”
• One or more Exchange Web Services names such as “autodiscover.domain.com”

Exchange Server 2010 continues this standard of using SSL by default on end user and server-to-server communications protocols.

Because of the default requirement for SSL, each Exchange server is automatically provisioned with a self-signed certificate when it is installed. However, because it is self-signed it is not trusted by any connecting clients. This results in problems such as:

• Untrusted certificate warning dialogs appearing for users connecting to Outlook Web App
• ISA Server firewalls failing to proxy HTTPS connections from web users to the Exchange server
• Other devices and third party software that cannot bypass untrusted certificates failing to connect at all

In the field we see several different workarounds being used to resolve those problems, such as:

• Configuring a Group Policy to trust the Exchange server’s self-signed certificate. This works for domain members but is not practical for non-domain members (e.g. staff home computers and mobile devices).
• Issuing a new SAN certificate for Exchange from a private certificate authority. Again this works for domain members but does not solve the issue for non-domain members. It also requires the provisioning and management of a Certificate Services server on the network.
• Configuring multiple IIS websites and Exchange virtual directories, and securing each one with a single-name SSL certificate. This can be a lot of effort and creates complexities that become hard to administer, as well as consuming multiple IP addresses to dedicate to each SSL-protected service.
• Removing the SSL requirement on Exchange services and connecting over HTTP instead. Because of the use of Basic Authentication for some of the Exchange services, this effectively exposes user credentials in clear text where they can potentially be compromised.
• Do nothing. This means that some applications will break and users will often need to accept a certificate mismatch or untrusted certificate prompt when connecting to Exchange.

As you can see, even though workarounds are possible they are not always practical to implement, especially in larger environments. They can create more administrative effort to implement and maintain, and may not solve all of the issues for some environments.

The worst case scenario is doing nothing, which ultimately trains users to be unconcerned about security and to view certificate mismatches and trust failures as something to simply ignore.

With all of that in mind, the business case is clear for purchasing SSL SAN certificates from a genuine commercial certificate authority to use with Exchange Server 2007 and 2010. For an outlay of as little as a few hundred dollars the business receives the benefits of:

• Far less administrative effort to implement and maintain SSL for Exchange services
• Compatibility with devices and applications that require connection to Exchange services over SSL
• Access to Exchange services such as Outlook Web App for remote workers without undermining the security of the network or encouraging insecure behaviour by users

Bio: Paul Cunningham is an Exchange Server specialist for a leading systems integrator in Australia. See more Exchange Server tutorials by Paul at ExchangeServerPro.com.