Updated on 9/20/2010 to include .NET Hotfix

When will Exchange Server 2010 support FIPS compliance?
Exchange Server 2010 SP1 provides for the ability to disable algorithms which are not FIPS 140-2 compliant. These algorithms are used for encryption, hashing, and signing within the Windows Server 2008 and Windows Server 2008 R2 operating systems that support Exchange Server 2010. When the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting is enabled in a Group Policy or Local Policy, it disables the use of non-FIPS compliant algorithms such as RC-4. In Exchange 2010 RTM, it caused certain functions to fail. The most notable issue was in Outlook Web App (OWA), as documented in Microsoft Knowledge Base Article KB977961, and in the web-based Exchange Control Panel (ECP).

What is FIPS?
Federal Information Processing Standards (FIPS) are standards utilized to define security and interoperability requirements for cryptographic algorithms that the US Government uses. The FIPS 140-2 publication and standard (Security Requirements for Cryptographic Modules - PDF) defines the cryptographic algorithms as well as standards for key generation and key management. There are several FIPS publications which define how to further secure information systems and provide a standard upon which systems can be evaluated.

For more information on how Microsoft products and libraries comply with FIPS 140, see FIPS 140 Evaluation.

The importance of FIPS compliance to specific customers
Within the United States our customers utilize several guidelines, checklists, and requirements for securing systems, all which call for this policy setting to be enabled on the application’s host operating system (OS). In addition we have customers that do business with the US Government or work in industries where there is significant government oversight.

This policy setting ensures that the host OS, Windows Server 2008 SP2 or greater and Windows Server 2008 R2 or greater, in this case, only utilizes cryptographic algorithms that have passed the Cryptographic Module Validation Program and have been certified by the National Institute for Standards and Technology. Try saying that really fast three times.

The Windows Server OS, specifically the Windows Cryptographic Service Provider (CSP) is responsible for leveraging FIPS compliant algorithms for cipher, hashing, signing and encryption and we don’t actually need to enable anything within Exchange Server 2010. Exchange 2010 does have to know how to process the information provided via the OS, OS components such as Internet Information Server (IIS), and the Windows CSP. Exchange 2010 was released without support for servers which had this setting enabled, but had support and testing aligned for release with Exchange 2010 SP1.

What happens when this policy setting is enabled?
In Exchange 2010 RTM, when the policy setting System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing is enabled on the Windows Server 2008 or Windows Server 2008 R2 OS, the Schannel Security Provider (SSP) disables Secure Sockets Layer (SSL) protocols which are not part of the FIPS 140 standard. When this policy setting is enabled only FIPS 140-2 approved cryptographic algorithms are utilized. Examples of FIPS 140-2 compliant algorithms are the Triple Data Encryption Standard (3DES) and Triple Data Encryption Algorithm (TDEA) cipher, Advanced Encryption Standard (AES) algorithm and the Secure Hashing Algorithm (SHA) for hashing. In addition only the Transport Layer Security for Secure Sockets Layer (TLS/SSL) protocols will be utilized.

For those of you who have enabled the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting on an Exchange 2010 server, you may have discovered two distinct issues. The first is that Outlook Web App on your Client Access Servers (CAS) appears to work but generates errors once the customer provides their username and password or smartcard PIN.

For those of us that have customers using Kerberos constrained delegation (KCD), OWA errors out with:
! An unexpected error occurred and your request couldn’t be handled

Expanding the Show Details link provides additional detail, specifically an exception message stating:
The type initializer for ‘Microsoft.Exchange.Data.Storage.GccUtils’ threw an exception

Additionally, an error event (Event ID 4999, Source: MSExchange Common) will be logged in the Application event log on the Exchange CAS.

The second issue is near-identical where the web-based ECP functionality, also provided by the CAS, will fail.

How will this be fixed?
In Exchange 2010 SP1, changes have been made to the code base, tested and verified, to support this setting. Exchange 2010 SP1 operates with support for FIPS 140-2 algorithms if the Windows Server 2008 SP2 and Windows Server 2008 R2 operating systems are configured to utilize the FIPS 140-2 algorithms for system cryptography.

My agency/organization/customer/co-worker asked about this support yesterday. When will Exchange Server 2010 SP1 be released?
Exchange 2010 SP1 has been released and can be downloaded here.

Are any updates required to get this functionality to work?
You need to deploy Exchange 2010 SP1. In addition, in order to utilize the Exchange Control Panel after enabling the FIPS compliance setting, you must install http://support.microsoft.com/kb/981119 on all your Client Access Servers.

Thanks for your time and my customers and I look forward to it as well!

Bob Christian II