Troubleshooting: Cryptographic Operation Errors Decrypting the Authentication Cookie

Version Affected: All
 
 

Overview

Transparent SSO or an OpenID app can fail with a cryptographic decrypt exception when the IdP tries to read an authentication cookie that was encrypted elsewhere. The log shows an entry similar to:

Exception: Error occurred during a cryptographic operation.
at System.Web.Security.Cryptography.HomogenizingCryptoServiceWrapper.HomogenizeErrors(Func`2 func, Byte[] input)
at System.Web.Security.FormsAuthentication.Decrypt(String encryptedTicket)

There are multiple potential causes, all related to a mismatch in the machine keys used to encrypt and decrypt the authentication cookie:

• See Cause 1 - Transparent SSO fails, and the two realms involved have different targetFramework values
• See Cause 2 - An OpenID app works on first login, but subsequent logins that hit a second IdP show Server_Error
• See Cause 3 - Transparent SSO fails intermittently across a load-balanced pool of IdPs

These causes are not related, so a fix for one cause will not resolve any of the others.

 

In this article

• Cause 1: Mismatched targetFramework Between Realms
• Cause 2: Realm's Machine Key Set to Isolate Apps
• Cause 3: Load-Balanced Nodes Each Auto-Generating Their Own Key

Cause 1: Mismatched targetFramework Between Realms

The two realms involved in Transparent SSO are using different targetFramework values in the <httpRuntime> section of their web.config. Even though the realms' machine keys otherwise look identical, a different targetFramework value causes .NET to compute the encryption differently, so the keys do not actually match.

Resolution 1:

1. Open the Admin Console for the realm in question, and go to the System Info tab.
2. Click Click to edit Web Config file.
3. Search for targetFramework and note its version:
   
4. Check the other realm involved and note its targetFramework version.
5. Match the targetFramework version across all participating realms. Use 4.5 unless you have a specific reason to use a different version.
6. Save the changes.

Cause 2: Realm's Machine Key Set to Isolate Apps

A cookie is created at first login to an OpenID app. If a subsequent login is handled by a second IdP, that IdP cannot read the cookie because the realm's Machine Key is configured to isolate applications from each other, giving each application its own independent key.

Resolution 2:

1. Open the Admin Console and go to the Post Authentication tab of the OpenID realm.
2. Click View and Configure FormsAuth keys/SSO token.
   
3. Under Machine Key, click Generate New Keys.
4. Save the changes so the same key is used consistently for this realm, allowing the cookie to be read across IdPs.

Cause 3: Load-Balanced Nodes Each Auto-Generating Their Own Key

Transparent SSO fails intermittently across a pool of load-balanced IdPs, when the affected realm's validation and decryption keys are set to auto-generate and isolate applications. Under this setting, each node in the pool independently generates its own random encryption key at runtime. A pre-authentication cookie encrypted by one node cannot be decrypted by a different node in the same pool, since each has its own key.

Resolution 3:

1. On one node, open the Admin Console and go to the Post Authentication tab of the affected realm.
2. Click View and Configure FormsAuth keys/SSO token, then under Machine Key, click Generate New Keys to generate a single, fixed set of keys.
3. Copy the resulting Validation Key and Decryption Key values, and paste them into the same realm's Machine Key settings on every other node in the pool.
4. Save the changes on every node. All nodes can now read cookies created by any other node in the pool.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.