Most Exchange organizations spend plenty of time examining their namespace, SSL certificate, load balancing and...
reverse-proxy options, but few spend as much thought on the different Exchange SSL-deployment choices. Understanding the three SSL options will go a long way toward making the right decision for your deployment.
Back when everyone was using Exchange 2003, SSL was still an optional -- though recommended -- configuration alternative for organizations that wanted to publish Exchange for external client access. With today's modern Internet, however, SSL is no longer optional.
Secure Sockets Layer (SSL) and its cousin Transport Layer Security are used by default to secure all client-to-server and server-to-server protocol sessions whenever possible, unless the protocol provides its own security mechanism, such as MAPI-RPC or RPC encryption.
Rather than blindly follow a configuration guide that may or may not give your specific Exchange organization the optimal benefits, understanding your SSL options helps you choose the right load-balancing and reverse-proxy solution.
Your three SSL options are pass-through, offload and bridging (Figure 1).
Each of these options describe the specific SSL session. For the sake of this tip, let's assume that there is at least a firewall between the public Internet and your Exchange servers. Additionally, all Exchange servers should be placed in protected interior networks, per Microsoft's support boundaries.
Exchange SSL option 1: SSL pass-through
SSL pass-through is the simplest option; when configured, SSL pass-through does not intercept the SSL sessions on network devices before they reach the client access server (CAS) role. The pass-through option is usually only suitable for smaller Exchange deployments with few connections.
SSL pass-through comes in two variants: One where an organization doesn't use load balancing or a reverse proxy, and another where it uses both. The specific load-balancing option doesn't matter; it can be Windows Network Load Balancing, a Microsoft Forefront Threat Management Gateway Server deployment or a hardware load balancer (HLB). The drawback is that the best load-balancing capability is the incoming connection's source IP address.
This isn't a problem in Exchange Server 2013, as this option is the type of Layer 4 load balancing that Exchange 2013 is designed to work with. For Exchange 2007 and Exchange 2010, however, SSL pass-through can cause uneven traffic to your CAS roles depending on your own specific traffic patterns. To evenly distribute the load in Exchange 2007 or Exchange 2010, you'll need a layer 7 HLB or reverse proxy that uses one of the next two options.
Exchange SSL option 2: SSL offload
SSL offload, commonly referred to as SSL termination, directs inbound SSL connections to the proxy device (HLB or reverse proxy), which is configured with the SSL certificate and private key in order to decrypt the SSL session.
The proxy then has full access to the protocol payload and can pre-authenticate the session, inject precise load-balancing headers and more, before connecting the session to Exchange via a non-SSL protocol.
SSL offload is useful for two reasons: First, it lets security systems inspect the network stream between the proxy and Exchange Server. Second, it removes the CPU overhead of SSL decryption on your Exchange servers.
If you're on a 32-bit version of Exchange, this overhead can prove critical. On modern hardware and hypervisors, it's possible to provide enough processor capacity to minimize the effects of the overhead on the cheap.
SSL offload, though, has these two major drawbacks:
- Because the network stream is unencrypted, it is open to inspection by security systems as well as hostile entities.
- Exchange does not perform SSL offload by default. You must disable SSL on the desired protocols, and then enable SSL offload so that Exchange still sends clients the correct SSL-enabled URLs.
SSL offload is not supported as of Exchange 2013 RTM.
Exchange SSL option 3: SSL bridging
SSL bridging, commonly referred to as SSL initiation, begins the same as SSL offload; inbound SSL connections are directed to the proxy. The proxy then uses the SSL certificate and private key to decrypt the SSL session and allows for the same traffic-inspection capabilities. In using SSL bridging, however, the proxy connects to the Exchange servers using an SSL-protected protocol, ensuring that the network stream between the proxy and Exchange is encrypted as well as secure.
The proxy's hostname and certificate do not have to be the same as those on the Exchange servers. The proxy device creates a new SSL session independent of the parameters the client uses. This flexibility allows Exchange admins to implement hybrid PKI solutions, where the proxy uses public certificate authority certificates and Exchange servers use internal certificates.
SSL bridging, however, does encrypt the network stream so that IDS applications and other security systems can't inspect the traffic once it leaves the proxy. If the proxy is in a perimeter network, this is often a required level of protection.
Make certain the SSL option you choose meets your specific requirements. Doing so ensures that your overall design meets expectations and reduces the likelihood of unexpected problems in your Exchange Server deployment.
About the author:
Devin Ganger is a messaging architect and technical writer with more than 15 years of experience in administering messaging systems, Windows, Unix and TCP/IP networks. Today, he works primarily with Exchange Server, Windows Active Directory and related Microsoft and third-party technologies. Ganger was recognized as a Microsoft MVP for Exchange Server from 2007 to 2011.