Resources For IT Professionals
Page Details
  • First published by (Microsoft, Microsoft Partner)
  • When: 28 Jul 2010 7:30 AM
  • Last revision by (Microsoft)
  • When: 17 Dec 2012 1:48 PM
  • Revisions: 148
  • Comments: 50
Options

Revision #130

Wiki  >  TechNet Articles  >  How to Configure SSL Offloading in Exchange 2010  >  Revision #130
How to Configure SSL Offloading in Exchange 2010
You are currently reviewing an older revision of this page.
Go to current version

This Exchange Wiki article explains how to configure SSL offloading for the Exchange 2010 protocols and client access services on an Exchange 2010 Client Access server (CAS).

When using a hardware load balancer to load balance traffic to CAS servers belonging to a CAS array, it can depending on the Exchange 2010 topology be beneficial to enable SSL offloading for the Exchange 2010 protocols and client access services on each CAS server in the CAS array.


Table of Contents

By enabling SSL offloading, you terminate the incoming SSL connections on the hardware load balancer instead of on the CAS servers in the CAS array. Doing so moves the SSL workload (encryption and decryption tasks) which is CPU intensive from the CAS servers to the HLB device(s). With CAS servers getting more and more responsibility (with the introduction of new features such as MailTips, Mailbox Replication Service (MRS)) and because it now also is the endpoint for MAPI clients, it can in some scenarios make sense to let the LB device(s) take care of the SSL workload. This could be true in an environment where the CAS servers are restricted to a limited number of CPUs (could be in virtual environments etc.).

Another important reason is the fact that you only can take advantage of layer 7 (L7) processing such as cookie-based persistence if you offload SSL to the LB devices or configure reverse SSL (see section later in this article). If you do not offload SSL or configure reverse SSL, you can only use source IP address based persistence, which isn’t ideal in large scale environments. This is especially true, if you have clients that appear to come from the same source IP address (such as when clients are located behind a NAT device etc.).
 
 
note Important

If you configure SSL offloading on an Exchange 2010 CAS server, all user passwords will be sent in clear between the HLB device(s) and the CAS servers, so it's important the traffic is sent over a secure network not accessible by malicious users. If the security policy within the organization states that all passwords should be sent in an encrypted form (even when occurring over a secure network), it's recommended to enable reverse SSL on the HLB device(s). In addition, it's recommended to enable reverse SSL, if the organization does not have a secure network in place between the HLB device(s) and the CAS servers or if there's no noticeable performance gain of offloading SSL to the HLB device(s) in the environment.

Most HLB devices support software SSL. When software SSL is used, the HLB device uses the general processor (CPU) to perform SSL encryption and decryption tasks. Since the general CPU also handles things such as load balancing, health checks and other administrative tasks, if you have thousands of users in your messaging environment, it’s recommended to use a HLB that has a separate CPU with the sole purpose of processing SSL workload.

When configuring SSL offloading in Exchange 2010, you must also enable SSL acceleration on the LB device(s). This is however outside the scope of this article as the method differs from vendor to vendor.

Conceptual diagrams

The following diagram illustrates client connectivity with SSL Offloading (SSL acceleration) enabled:

The following diagram illustrates client connectivity with SSL bridging (Reverse SSL) enabled:



 

note Note
This Wiki page has been reviewed by the Exchange Product group and all included steps have been validated and approved. Also bear in mind that the steps for how to configure SSL offloading for Autodiscover and Exchange Web services are less complex when using Exchange 2010 SP1 and not Exchange 2010 RTM as it won't be necessary to modify any web.config files in Exchange 2010 SP1.

 

 

Configuring SSL Offloading for Outlook Web App (OWA)

To configure SSL offloading for Outlook Web App (OWA), you must perform two steps on each CAS server in the respective CAS array. First, you must add a SSL offload REG_DWORD key. To do so, open the registry editor and navigate down to:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA


Under this registry key, create a new REG_DWORD key named “SSLOffloaded” and set the value for this key to “1”


Next disable the requirement for SSL on the OWA virtual directory. To do so,  open the IIS Manager and expand the Default Web Site. Under the Default Web Site, select the “owa” virtual directory. Under features view, double-click on “SSL Settings”.

 


Finally, open a command prompt window and run “iisreset /noforce” in order for the changes to be applied.




Configuring SSL Offloading for Exchange Control Panel (ECP) 


Unlike OWA, configuring SSL offloading for the Exchange Control Panel (ECP) doesn’t require a registry key to be set. Well, to be more specific ECP will use the same registry key as the one we set for OWA.

So in order to enable SSL offloading for ECP, the only thing we need to do is to disable the SSL requirement on the ECP virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site, select the “ecp” virtual directory. Under features view, double-click on “SSL Settings”.

So in order to enable SSL offloading for ECP, the only thing we need to do is to disable the SSL requirement on the ECP virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site, select the “ecp” virtual directory. Under features view, double-click on “”.

Now uncheck ”Require SSL” and click “Apply” in the Actions pane.


Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.


Configuring SSL Offloading for Outlook Anywhere (OA)


To enable SSL offloading for Outlook Anywhere only requires one step which depending on whether Outlook Anywhere already is enabled or not can be done via the Exchange Management Console (EMC) or the Exchange Management Shell (EMS).

If you haven’t yet enabled Outlook Anywhere yet, you can select to use SSL offloading when running the “Enable Outlook Anywhere” wizard. You can access this wizard by right-clicking on the respective CAS server in EMC and select “Enable Outlook Anywhere” in the context menu.

 
This brings up the wizard where you enter the external host name to be used and check “Allow secure channel (SSL) offloading”.

If you already enabled Outlook Anywhere in your environment, you need to use the Set-OutlookAnywhere cmdlet to enable SSL offloading. If this is the case, open the Exchange Management Shell and type the following command:

Set-OutlookAnywhere –Identity CAS_server\RPC* -SSLOffloading $true

Running the above command will disable the requirement for SSL for the RPC virtual directory in IIS, which means we don’t need to do so manually like it’s the case with the other services/protocols.

Configuring SSL Offloading for the Offline Address Book (OAB)

To enable SSL offloading for the Offline Address Book (OAB) you just need to remove the SSL requirement on the OAB virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “OAB” virtual directory. Under features view, double-click on “SSL Settings”.


Now uncheck ”Require SSL” and click “Apply” in the Actions pane.
 


Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.



Configuring SSL Offloading for Exchange ActiveSync (EAS)

Some of you may probably recall you have read on Microsoft TechNet and various other places, that it isn't supported . This used to be true but is now fully supported (although the Exchange documentation on Microsoft TechNet hasn’t been updated to reflect this yet).

note Important
SSL offloading for Exchange ActiveSync is only supported at the Internet ingress point. It’s still not supported in CAS-CAS proxy scenarios between Active Directory sites.

Configuring Exchange ActiveSync to support SSL offload is very simple. You only need to remove the requirement for SSL in IIS. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “Microsoft-Server-ActiveSync” virtual directory. Under features view, double-click on “SSL Settings”.


Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

 
Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.

 Configuring SSL Offloading for Exchange Web Services (EWS)

 

note Important
With Exchange 2010 SP1, you will no longer need to modify the web.config file. Performing the process below with the new SP1 files will cause EWS to fail activation. To offload SSL for EWS, you only need to remove the SSL requirement from the IIS virtual directory as described in the steps above.


To configure SSL offloading for Exchange Web services in Exchange 2010 RTM, you must perform two modifications. The first one is to remove the SSL requirement for the EWS virtual directory in IIS. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “EWS” virtual directory. Under features view, double-click on “SSL Settings”.

 

Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Next step is to make a change to the configuration file (web.config) for the EWS virtual directory. This file can be found under C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews and be modified using a text editor such as Notepad.

note Important
It's recommended you take a backup of the web.config file before you perform the next step.
In the web.config file, replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.
The new SP1 web.config file contains binding entries for both httpTransport and httpsTransport that match the Binding name.  For example, there is an EWSHttpBinding and an EWSHttpsBinding now.
Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.
note Important
With Exchange 2010 SP1, you will no longer need to modify the web.config file. To offload SSL for EWS, you only need to remove the SSL requirement from the IIS virtual directory.

Configuring SSL Offloading for Autodiscover Service (AS)

To enable SSL offloading for the Autodiscover service, you must perform the same steps as those applied to the Exchange Web service virtual directory.

note Important
With Exchange 2010 SP1, you will no longer need to modify the web.config file. Performing the process below with the new SP1 files will cause Autodiscover to fail activation. To offload SSL for Autodiscover, you only need to remove the SSL requirement from the IIS virtual directory as described in the steps above.



To configure SSL Offloading for Autodiscover on Exchange 2010 RTM, open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “Autodiscover” virtual directory. Under features view, double-click on “SSL Settings”.


Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Next you need to change the configuration file (web.config) for the Autodiscover service virtual directory. This file can be found under C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover and be modified using a text editor such as Notepad.

note Important
It's recommended you take a backup of the web.config file before you perform the next step.
 
In the web.config file, replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.

The new SP1 web.config file contains binding entries for both httpTransport and httpsTransport that match the Binding name.  For example, there is an AutodiscoverBasicHttpBinding and an AutodiscoverBasicHttpsBinding now.
Finally open a command prompt windows and run “iisreset /noforce” so that the changes are applied.

SSL Offloading in an Exchange 2003/2010 Coexistence Scenario

During a coexistence scenario where you have a mix of Exchange 2003 and Exchange 2010 servers in the organization, one of the first steps you need to perform after having deployed Exchange 2010 Client Access Servers is to change DNS, so that Exchange 2003 users access their mailbox via a set of Exchange 2010 Client Access servers in a Client Access array (CAS array).

In such a scenario it's fully supported to enable SSL offloading on the load balancer used to distribute client traffic across the CAS server in the CAS array.

Outlook Web App (OWA)

When configuring coexistence between Exchange 2003 and Exchange 2010, one of the steps you must to is to configure an OWA 2003 redirect URL on the OWA 2010 virtual directory. When doing so, you introduce a legacy FQDN that will be associated with Exchange 2003. This legacy FQDN is used when configuring the OWA 2003 redirection URL. The legacy URL is configured like the following:

https://legacy.contoso.com/exchange

Because the Exchange 2020 CAS server will do a redirect when sending the client to Exchange 2003, it will work fine with SSL offloading enabled on the load balancer used with Exchange 2010.
 

Exchange ActiveSync (EAS)

TBD.
Outlook Anywhere (OA)

TBD.

Using a Script to Enable SSL Offloading

If you're working with a large organization with many Exchange 2010 Client Access services , you may want to accelerate the steps we went through above. To configure SSL offloading using a scripted method, see this blog post.

The following cmdlets are a summary of tasks required to configure SSL offloading for Exchange Server 2010 SP1 on each Client Access server:


Set-OutlookAnywhere –Identity "$($env:COMPUTERNAME)\RPC (Default Web Site)" -SSLOffloading $true

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA' -Name SSLOffloaded -Value 1 -PropertyType DWORD

Import-Module webadministration

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/OWA"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/ECP"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/OAB"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/EWS"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/Microsoft-Server-ActiveSync"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/Autodiscover"

iisreset /noforce



Notes on reverse SSL

If you enable reverse SSL (aka SSL bridging) on the HLB devices, you will not need to perform the above steps on each CAS server in the CAS array. However, bear in mind enabling reverse SSL on the HLB device(s) will mean the SSL workload (encryption and decryption tasks) which are CPU intensive won't be moved away from the CAS servers. Instead, the SSL workload will occur on both the HLB device(s) and the CAS servers. With that said, if you do not enable reverse SSL, passwords will be sent in clear between the HLB device(s) and the CAS servers, so it's important this traffic occurs over a secure network not accessable by malicious users.

Whether you should use Exchange 2010 SSL offloading or the reverse SSL method is up to the respective organization to decide. If the CAS servers can handle all expected workload and if you do not have a secure network in place between the HLB device(s) and the CAS servers, it's recommended to enable reverse SSL.


note Credits
Thanks a lot to the MCM/MCA community for the great feedback and input (primarily on the performance and security implications of implementing SSL offloading).