我们在旧版 ASP.NET Web 环境中遇到了有关 web.config 加密的非常令人担忧的问题。
- 情况
多年来，我们的 Web 部署过程涉及使用 TFS (AzureDevOps) 编译代码、合并 web.config 文件，然后调用 aspnet_regiis 来加密存储在其中的凭据 - 所有这些都使用部署到我们所有服务器的公用密钥。这个过程多年来一直完美无缺 - 直到大约两天前。
- 问题
大约两天前，我们突然开始看到应用程序故障可追溯到最近部署的应用程序运行时的“无法解码 OAEP 填充”错误。现在，通过 aspnet_regiis 加密的任何新部署的应用程序或 web.config 文件将不会在任何其他服务器上解密，尽管在每台目标计算机上指定相同的密钥。
- 我们尝试过的事情
- 其他文章中对此错误的研究指出，这通常是由于加密过程中公钥/私钥使用不当造成的。由于此过程是自动化的，并且已经运行多年，因此我们排除了这种可能性。
- 我手动重新创建了密钥容器，并从原始导出的 XML 源重新导入了密钥
- 我验证了加密提供程序的目标是部署到所有环境的公共密钥容器，并且提供程序使用机器密钥存储。
- 我验证了密钥容器上是否存在所有相关权限。
- 我通过 ProcMon 验证确实使用了正确的机器密钥。
- 我创建了一个“示例”web.config，将其复制到三台不同的计算机上，并部署了相同的公用密钥，并对“虚假”connectionStrings 部分执行了加密。每种情况下的“CipherValue”都不同，并且这些加密文件都无法在任何“其他”服务器上解密。
我的理论围绕这样一个概念：aspnet_regiis 的行为中的
某些东西
已经改变了
系统之间的密码和/或哈希算法不同
- 尽管 RSA 提供商被告知要使用特定的密钥容器，但它却以某种方式使用了特定于机器的私钥，该私钥在服务器之间必然有所不同。
-
环境：Windows Server 2016 版本 1607 w/IIS 10.0（服务器）
Windows 10 版本 22H2（桌面版）
我正在寻找任何方法来恢复部署到所有环境的公共密钥允许公共加密/解密的行为，就像过去“几年”的情况一样。我研究了 aspnet_regiis 的重大更改，但一无所获。
经过近两天的研究，我们能够将上述问题追溯到损坏的机器密钥。我们不知道密钥是如何损坏的，但恢复它已经解决了问题。