迁移至新IIS实例的ASP.NET Core站点出现CryptographicException问题

核心结论 #

这个问题既有旧站点Cookie导致的临时因素，也存在数据保护密钥配置的深层问题，两者共同引发了偶尔出现的解密失败报错。

旧Cookie的临时影响 #

旧Windows 2012服务器上的ASP.NET Core站点会用自身的数据保护密钥加密三类内容：

• Identity登录状态Cookie
• .AspNetCore.Mvc.CookieTempDataProvider临时数据Cookie
• 防伪令牌（Antiforgery Token）

用户浏览器中保存的这些Cookie尚未过期时，访问新服务器的站点会携带旧Cookie。由于新服务器没有旧站点的加密密钥，尝试解密这些内容就会触发CryptographicException（密钥未找到），进而引发防伪令牌验证失败、TempData加载失败的连锁错误。这类问题会随着旧Cookie自然过期（或用户手动清除浏览器缓存）逐渐消失，但属于治标不治本的临时现象。

深层配置问题排查 #

你已经设置了应用程序池的LoadUserProfile=true，但仍有以下可能的配置疏漏：

• 数据保护密钥未同步：ASP.NET Core默认将数据保护密钥存储在服务器本地的%LOCALAPPDATA%\ASP.NET\DataProtection-Keys目录。迁移时如果没有将旧服务器该目录下的密钥文件复制到新服务器，新服务器会自动生成一套全新的密钥，无法解密旧Cookie。
• 应用程序池标识不一致：如果旧站点应用程序池使用的是特定域账户/本地账户，而新站点用了默认的ApplicationPoolIdentity，即使开启LoadUserProfile=true，不同标识对应的本地存储路径也不同，新服务器依然无法读取旧密钥。
• 自定义数据保护配置未迁移：若旧站点曾通过代码配置过自定义密钥存储（比如数据库、共享文件夹），新站点未同步该配置的话，也会导致密钥体系不一致。

解决建议 #

1. 临时缓解方案：

   • 缩短旧Cookie的过期时间（在旧站点迁移前修改配置，让用户的旧Cookie尽快失效）；
   • 在新站点的响应中添加清除旧Cookie的逻辑（针对.AspNetCore.Identity.Application、.AspNetCore.Mvc.CookieTempDataProvider等Cookie）。

2. 彻底解决措施：

   • 同步密钥文件：将旧服务器%LOCALAPPDATA%\ASP.NET\DataProtection-Keys目录下的所有文件复制到新服务器对应路径，确保新服务器应用程序池标识对该目录有读写权限；
   • 配置共享密钥存储：统一配置数据保护密钥到共享存储（如网络共享文件夹、SQL Server），示例代码（Program.cs）：

     builder.Services.AddDataProtection()
         .PersistKeysToFileSystem(new DirectoryInfo(@"\\shared-server\data-protection-keys"))
         .SetApplicationName("YourAppName");
     

   • 统一应用程序池标识：确保新站点应用程序池使用与旧站点相同的账户，避免因标识差异导致密钥存储路径不一致。

内容的提问来源于stack exchange，提问作者Crag