Resources For IT Professionals
Post an article
Wikis - 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
RSSSubscribe to Article (RSS)
Can You Improve This Article?
Positively! Click Sign In to add the tip, solution, correction or comment that will help other users.

Report inappropriate content using these instructions.
Wiki  >  TechNet Articles  >  How to Configure SSL Offloading in Exchange 2010

How to 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

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

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

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

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

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


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

 

, , , , , , , , , , , , , , , ,
Sort by: Published Date | Most Recent | Most Useful
Comments
  • 5 Aug 2010 12:18 AM

    Great article Henrik. The section on web.config repeats itself, I guess the last part should be moved to the end after the AS bit?

  • 5 Aug 2010 12:39 AM

    Thanks Morten. Should be fixed now. The Wiki editor sometimes mess things up... :(

  • 16 Sep 2010 3:55 AM

    Thanks for this info.

    Should not you also disable FBA (Forms Based Authentication) on the websites in Exchange 2010?

    I can offload the SSL with our F5 loadbalancer, but only when FBA is disabled.

    I read that FBA requires SSL.

    I want to use single sign on on internal web

    I don't use external web access (yet)

  • 24 Sep 2010 1:17 AM

    Shouldn't be necessary to disable FBA as you don't disable SSL on the OWA vdir, you only disable the requirement. If this doesn't work for you you might want to consider the "reverse SSL" approach where you use SSL between client and F5 and between F5 and CAS servers.

    Henrik

  • 5 Oct 2010 7:51 AM

    When connecting to the http OWA site of the server, I always get a 302 return code and all communication turns into https.

    When connecting to the F5 loadbalancer OWA site, the client-F5 communications is https and F5-CAS communications seems to be http.

    How can I connect http to the server without disabling FBA? (I mean choosing single sign-on Windows Authentication)

    Is Windows Integrated Authentication much slower then FBA?

  • 29 Nov 2010 12:30 PM

    Henrik - Question about SSL offloading the Exchange proxy/redirection. If we are clearing the HTTPS requirement on each IIS website and we have two (or more) CAS arrays that are also using SSL offloading; do we also need to modify the InternalNLBBypassURL to http and not https? Using only the methods described above an Exchange proxy to another CAS array will fail, correct?  Thanks for your work in the community.

  • 20 Dec 2010 5:18 PM

    I have a quick question. I am getting ready to deploy a Cisco ACE load balancing module to load balance internal and external CAS connections across the CAS array. I was wondering if I should be able to connect to OWA with forms based authentication enabled and SSL offloading enabled via http. Currently, with SSL offloading enabled on Exchange 2010 SP1, when I connect over HTTP, I get redirected to HTTPS. This is happening when I connect directly to any members in the CAS array.

    Also, do I need to update all virtual directory internal / external URLs to reflect http vs. https?

    Your help is greatly appreciated.

  • 21 Dec 2010 1:52 AM

    techstuff231: Yes you can use FBA with SSL offloading configured. Also no you don't need to change vdir URL.

  • 22 Dec 2010 6:11 PM

    Henrik,

    Thanks for getting back to me on the SSL Offloading with forms based authentication enabled.

    I'm wondering what your opinion is on using either TMG or UAG in the perimeter network. I can't decide which one to use. Also, where should I offload SSL traffic when reverse proxies such as one of these are used before a hardware based load balancer? I'm planning on offloading SSL encryption and decryption to our Cisco ACE. I've read over your article "Load Balancing Exchange 2010 using a HLB" and noticed that you state that traffic traversing through a reverse proxy should not use the VIP/FQDN of the load balancer. Can you tell me what the ideal configuration would look like in your opinion given both a reverse proxy and hardware based load balancer with SSL Offloading enabled on the CAS array?

  • 26 Dec 2010 7:08 PM

    I find ASP.NET 2.0.50727.0 event 1309 in event log

    how to fix it!

Page 1 of 3 (28 items) 123