ASP.Net MVC5：Web.Config连接字符串加解密方法存疑咨询

Great question—using aspnet_regiis.exe to encrypt connection strings is a common approach, but it has several easy-to-miss pitfalls that can break your application. Let’s walk through each common issue and how to resolve them:

1. Machine Key Mismatch (Multi-Server or Deployment Scenarios) #

Problem: #

By default, aspnet_regiis.exe uses the server’s auto-generated machine key to handle encryption/decryption. If you encrypt locally and deploy to a server (or use a load-balanced setup with multiple servers), each machine has a unique auto-generated key. This means the target server(s) won’t be able to decrypt the connection string, and your app will throw a decryption error.

Fix: #

• Define a static, shared machineKey in your Web.Config file. Use the same key across all servers in your environment. You can generate a secure machine key and add it under the <system.web> section:

  <system.web>
    <machineKey validationKey="YOUR_SECURE_VALIDATION_KEY" 
                decryptionKey="YOUR_SECURE_DECRYPTION_KEY" 
                validation="SHA1" 
                decryption="AES" />
  </system.web>
  

• Always run the encryption command directly on the target server(s) instead of encrypting locally first. This ensures the encryption uses the server’s (or shared) machine key.

2. Permission & Identity Context Issues #

Problem: #

The encryption/decryption process depends on the security context of the user running aspnet_regiis.exe. If you run the command as your local user, but your IIS app pool runs under a different identity (like ApplicationPoolIdentity or a custom service account), the app pool won’t have permission to access the encryption key, leading to decryption failures.

Fix: #

• Run Command Prompt as Administrator when executing aspnet_regiis.exe—this ensures the command has the necessary permissions to modify Web.Config and access machine key resources.
• If your app uses a custom service account for the app pool, run aspnet_regiis.exe under that same account (use the runas command) to align the security context.

3. Incorrect aspnet_regiis.exe Version/Architecture #

Problem: #

There are multiple versions of aspnet_regiis.exe for different .NET Framework versions (e.g., v2.0, v4.0) and architectures (32-bit vs 64-bit). Using the wrong version can result in encrypted connection strings that your MVC5 app (targeting .NET 4.x) can’t read.

Fix: #

• For ASP.NET MVC5 (which uses .NET Framework 4.5+), use the aspnet_regiis.exe located at:
  • 32-bit: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe
  • 64-bit: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe
• Match the architecture to your IIS app pool’s enabled bitness (check IIS Manager → Application Pools → Advanced Settings → Enable 32-Bit Applications).

4. Path Misconfiguration #

Problem: #

If you provide an incorrect folder path to the -pef/-pdf commands, aspnet_regiis.exe might fail to locate Web.Config, or encrypt/decrypt the wrong file entirely. This is common when using relative paths or mixing up IIS Express vs local IIS physical paths.

Fix: #

• Always use the absolute physical path to your Web.Config folder (e.g., C:\inetpub\wwwroot\YourMvcApp). Avoid relative paths, especially when running the command from a different directory.
• Verify that the path points directly to the folder containing your root Web.Config (not a subfolder like Views).

5. Lost Encryption After Configuration Changes #

Problem: #

If you modify the connection string (or any part of the <connectionStrings> section) after encryption, the modified content will remain in plaintext. Additionally, if you deploy a new Web.Config file, you’ll lose the encrypted content and need to re-encrypt.

Fix: #

• After making any changes to the connection string, re-run the encryption command to re-secure the section.
• Store a backup of your plaintext connection string in a secure location (not in source control) so you can restore it if needed.

Best Practices Recap #

• Encrypt connection strings on the target server, not locally.
• Use a shared machine key for multi-server environments.
• Always run aspnet_regiis.exe as Administrator with the correct .NET version/architecture.
• Backup plaintext connection strings securely.

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