Error Readout:
Exception: System.Web.HttpException
Message: Authentication of viewstate failed.  1) If this is a cluster, edit configuration so all servers use the same validationKey and validation algorithm.  AutoGenerate cannot be used in a cluster.  2) Viewstate can only be posted back to the same page.  3) The viewstate for this page might be corrupted.
Source: System.Web
   at System.Web.UI.LosFormatter.Deserialize(String input)
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()


Fix:
I encountered the above error the other day. Since the server wasn't on a web farm I was a little confused. The fix I ended up using was updating the web.config key to

requiressl=true


Explanation:
The next thing I asked myself was how can that key affect the viewstate. With some serious investigation into viewstate and best practices I finally made the link of how our applications viewstate is tied to session state which is tied to SSL when the session cookies are encrypted manually, a step (encrypting our own session cookies manually) we did because we are still running asp.net 1.1.

In .net 1.1 there is a property called "ViewStateUserKey" located in the viewstate, this key adds user-specific information to the view state. When the request is processed, ASP.NET extracts the key from the view state and compares it against the ViewStateUserKey of the running page. If the two match, the request is considered legitimate; otherwise an exception is thrown. In our application we use the Session.SessionID to set the property. This is where my problem starts.

When a user fills out a form utilizing viewstate to create an account to login to our system the user establishes a viewstate in their asp.net page.  In order to make the view state slightly more secure we give the viewstateuserkey the same value as the session ID. The session ID is a much better fit because a session ID is unpredictable, times out, and varies on a per-user basis
[http://msdn.microsoft.com/en-us/library/ms972969.aspx]

Once the user has completely filled out the form, we authenticate them.  This is where my error occurs [See beginning of post].


The error is caused because the session id is now encrypted. It's encrypted because our security team said, all information stored in cookies is to be secured. Our team consequently set up a flag in the global.asax file that states if this flag is set to true it should grab the session id out of each cookie and encrypt it. The reason we did this by hand is because asp.net 1.1 does not offer secure cookies with one easy key change in the web.config [NOTE: In asp.net 2.0 all you have to do is have the requiressl=true and you are done].

Now understanding that our session ID is tied to our viewstateuserkey you can understand the viewstateuserkey is now invalid because the session ID is a different value, simply because it's encrypted and the server does not know to decrypt it.  [NOTE: The session ID may still be the same value, it's just encrypted.] Now asp.net states the viewstateuserkey is invalid and pumps out the error you have seen above.

To fix this I simply change requiressl=true in the web.config.  How does requrie ssl affect an encrypted session id within a cookie that I set to encrypt? Well, when requiressl is not on but you are sending the server a secure cookie value, which we did since we created our own secure cookies in asp.net 1.1  the server doesn't know to decrypt the cookie because requiressl is not turned on [apparently you have to send secure cookies over ssl in asp.net 1.1 and possibly other run times, I didn't know this] which in turn invalidates the viewstateuserkey because the viewstateuserkey uses the session ID which is encrypted in the secure cookie.

What made this confusing for me is the first part of the form worked without a hitch. It's when the user authenticates when the error arose. The reason for this being that the requiressl key is not applicable until authentication happens. If you'll notice the requiressl key is nested in the authentication element in the web.config file.  Additionally we don't encrypt the cookie until the user is authenticated.  Sooo, the first few postbacks for our page were just collecting information.  It wasn't until we authenticated the user to our system that requiressl actually cared if we had secure cookies or not.


Overview
Viewstateuserkey is set to the session ID.

Session ID is encrypted and the updated value is set to the viewstateuserkey

requressl being turned on tells the server to decrypt session id in which case allows the viewstateuserkey to remain valid with the server.