Recently, I came across an issue where the customer faced an FIPS (Federal Information Processing Standards) related error on the .aspx pages which had debug=”true”. His ASP.net application was hosted on IIS7 running on Windows Server 2008 SP2. And, he was able to reproduce the issue using a very simple page. The error message was:
In Windows Server 2008, the FIPS related registry key is:
With the setting "Enabled"=dword:00000000 we know the FIPS enforcement is disabled.
While troubleshooting, we checked the Local Security Policy setting on the server, at Administrative Tools -> Local Security Policy -> Local Policies -> Security Options -> “System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing” and it showed that it was disabled.
The customer said that sometime back his domain administrators enabled FIPS on their Windows Server 2003 DC and that they enforced it domain-wide using Group Policy. They had then disabled the setting due to the application starting to fail with the Parser Error.
The customer did have a workaround, they can follow the article Disabling the FIPS Algorithm Check i.e. adding <enforceFIPSPolicy enabled="false"/> in their web.config file, however the customer was keen to know the cause of the issue..
So, we know on Windows Server 2003, the registry key for FIPS is
With this in mind, we checked the registry hive on the customer’s WIN2K8 server and there was this WIN2K3 dword value set ("fipsalgorithmpolicy"=dword:00000001). This was in fact causing the issue. It looked like the Win2k3 domain Group Policy added the registry key on the Windows Server 2008 but did not change the value of the key back when the Group Policy was changed.
I tried to reproduce the issue on my own server by forcing FIPS using Windows Server 2003 DC on my Windows Server 2008 IIS server, and the registry key does gets modified when I enable FIPS from GPO. After disabling FIPS from GPO I did “gpupdate /force” from the command prompt on my Windows Server 2008 server and the registry value is changed from 1 to 0.
To resolve the customer’s problem, we removed "fipsalgorithmpolicy"=dword:00000001 from [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa].
Doing a bit more research into the mechanics of the issue, here is what I believe happens: first .NET checks to see if the applicable config file (web.config) has the FIPS enforcement disabled. If the config file doesn't have it disabled then it calls BCryptGetFipsAlgorithmMode (public API) to see what is set in the registry. Inside BCryptGetFipsAlgorithmMode it first reads "HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled". If that is not set it then reads "HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy"