Recipe10.5.Enabling SSL Offloading

Recipe 10.5. Enabling SSL Offloading

Problem

You want to use a hardware SSL accelerator in front of your Outlook Web Access server.

Solution

To enable SSL offloading when you are not using forms-based authentication, perform both of the following procedures. If you are using forms-based authentication, you only need to make the registry modification.

Modifying the registry

1. Log on to the Exchange server that hosts SSL-enabled connections for your users. In a front-end/back-end topology, this will be the front-end server; otherwise, it'll be the back-end server.

2. Open the Registry Editor (regedit.exe).

3. Navigate to:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA

4. Right-click the OWA subkey and select New DWORD Value.

5. Name the new value SSLOffloaded and give it a value of 1.

6. Quit the Registry Editor.

Registering the ISAPI filter

1. Contact Microsoft Product Support and get a copy of ExFeHttpsOnFilter.dll (It's free, but they don't make it generally available, so you'll have to call them and reference MS KB 327800).

2. Log on to the Exchange server that hosts SSL-enabled connections for your users. In a front-end/back-end topology, this will be the front-end server; otherwise, it'll be the back-end server.

3. Copy the DLL to the exchsrvr\bin directory on the target Exchange server.

4. Launch the IIS Manager snap-in and expand the Local Computer and Web Sites nodes.

5. Right-click the Default Web Site entry and select Properties.

6. Switch to the ISAPI Filters tab and click the Add button.

7. In the Filter Name field, type ExFeHTTPSOn. In the Executable field, specify the location of the DLL you copied in step 3 and click OK.

8. If necessary, use the Move up and Move down buttons to make sure that the newly added filter is before the ExchFilt filter.

9. Restart the IISAdmin and W3SVC services.

Discussion

There are two primary types of SSL acceleration devices. The first are plug-in cards that you put in your server. They provide an interface to the Windows CryptoAPI layer such that CryptoAPI calls made by applications like IIS and Exchange are offloaded to the cards. Examples include the HP/Atalla AXL600L and the nCypher nFast card. You don't have to do anything special to make these cards work with Exchange. The other type of accelerator is usually built into a hardware IP management device. Examples of this type include the F5 Big-IP line, the Alteon 310, and the Cisco SCA 11000 series. These devices are the ones that require the measures described in the Solution section, at least in some cases. There are three scenarios in which you might be using SSL acceleration in conjunction with Exchange:

1. SSL passes from the client straight to the front-end server, with no intermediate devices or appliances. In this case, you don't have to apply the steps above.

2. SSL passes from the client to an intermediate appliance or device (including the devices described above or an ISA Server computer) that terminates the SSL connection before it reaches the front-end. In that case, client-appliance communications use SSL, but communications from the appliance to the front-end server use plain HTTP. What you do next depends on whether you're using forms-based authentication (FBA):

   • If you are not using FBA, you need to apply the ExFeHTTPSOnFilter filter and apply the SSLOffloaded registry key.

   • If you are using FBA, you need only to apply the registry change.

3. The client's not using SSL. You shouldn't use this configuration over the Internet; on corporate networks, it may sometimes be necessary. In that case, you don't need to make the changes described in this recipe.

These devices can terminate the SSL connection, or they can pass it through directly to the target host. The most common configuration is usually to have the device terminate the session and establish a new one to the target Exchange server, as this facilitates load balancing. In this configuration, though, you have to apply the ExFeHttpsOnFilter trick described in this recipe, or OWA won't have any idea that SSL was originally in use, so the links it generates will start with http:// and not https://.

These machinations all leave aside the larger question of whether it actually makes sense to buy the first kind of accelerator. Generally, SSL isn't the bottleneck for front-end servers; the boundary we normally use is that if the server is handling more than 100 concurrent SSL handshakes per minute, it might make sense to buy an accelerator. The handshake is the most resource-intensive component of SSL traffic; once it's completed, the ongoing encryption of passing traffic causes fairly low overhead.

See Also

MS KB 327800 (A new option that allows Exchange and OWA to always use SSL (HTTPS)) and MS KB 307347 (Secure OWA Publishing Behind ISA Server May Require Custom HTTP Header)