Configure SSL Offloading in Exchange 2010

How to Configure SSL Offloading in Exchange 2010.

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

• Configuring SSL Offloading for Outlook Web App (OWA)
• Configuring SSL Offloading for Exchange Control Panel (ECP)
• Configuring SSL Offloading for Outlook Anywhere (OA)
• Configuring SSL Offloading for the Offline Address Book (OAB)
• Configuring SSL Offloading for Exchange ActiveSync (EAS)
• Configuring SSL Offloading for Exchange Web Services (EWS)
• Configuring SSL Offloading for the Mailbox Replication Proxy Service (MRSProxy)
• Configuring SSL Offloading for Autodiscover Service (AS)
• Using a Script to Enable SSL Offloading
• Notes on reverse SSL

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

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

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”

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

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)

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

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.

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.

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)

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

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

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.

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/exchangeBecause 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 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.