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.

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.

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

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/SP2 and not Exchange 2010 RTM as it won't be necessary to modify any web.config files when these service packs has been applied.

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”

Configuring SSL Offloading for Exchange Control Panel (ECP) 

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”.

Configuring SSL Offloading for Outlook Anywhere (OA)

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.
 

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).

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”.

 Configuring SSL Offloading for Exchange Web Services (EWS)

Important
With Exchange 2010 SP1 and SP2, you will no longer need to modify the web.config file. Performing the process below with the new SP1 or SP2 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”.

Important
It's recommended you take a backup of the web.config file before you perform the next step.

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 the Mailbox Replication Proxy Service (MRSProxy)

The Mailbox Replication Proxy (MRSProxy) service is installed on every Exchange 2010 Client Access server. MRSProxy helps to facilitate cross-forest move requests and mailbox move requests to Office 365. By default, MRSProxy is disabled. If enabled, it's enabled in the remote Exchange forest (aka source Exchange forest). Although the MRSProxy service runs under Exchange Web Services (EWS) it's not supported to configure SSL offloading for this service.

The reason for this is because the MRSProxy service code expects the traffic to be signed/encrypted. This means that you must configure SSL bridging for this to work.

Configuring SSL Offloading for Autodiscover Service (AS)

Important
With Exchange 2010 SP1 and SP2, you will no longer need to modify the web.config file. Performing the process below with the new SP1 or SP2 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”.

Important
It's recommended you take a backup of the web.config file before you perform the next step.

SSL Offloading in an Exchange 2003/2010 Coexistence Scenario

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 accessible 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.

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).