Encrypting Web.config Configuration in .NET

Securing sensitive data such as database connection strings, API credentials, and identity secrets within a web.config file is a critical requirement in .NET application architecture. .NET addresses this through a feature called Protected Configuration, which encrypts specific XML sections directly within the configuration file using cryptographic providers such as DPAPI or RSA. This article explains how .NET encrypts and decrypts web.config files, the built-in providers available, the command-line and programmatic approaches to implement encryption, and how runtime decryption operates automatically.

The Protected Configuration Architecture

.NET does not encrypt the entire web.config file as a single blob. Instead, it encrypts individual XML sections (such as <connectionStrings> or <appSettings>) while keeping the overall XML schema and non-sensitive nodes readable.

When an XML section is encrypted, .NET replaces the raw configuration node with an <EncryptedData> element that contains the cipher text, key details, and metadata required for decryption.

Built-In Encryption Providers

.NET supplies two primary ProtectedConfigurationProvider implementations out of the box:

1. DataProtectionConfigurationProvider (DPAPI): Uses Windows Data Protection API to encrypt configuration sections. It relies on machine-level or user-level keys tied directly to the Windows OS. It is easy to configure because it requires no key management, but it is restricted to single-server environments because keys cannot be exported across multiple machines.
2. RsaProtectedConfigurationProvider (RSA): Uses public-key cryptography via RSA encryption. This is the default provider for ASP.NET. It allows you to create, export, and import custom RSA encryption key containers across multiple servers, making it the standard choice for web farms and load-balanced environments.

Encrypting with aspnet_regiis.exe

The most common method for encrypting configuration files in traditional .NET Framework applications is the ASP.NET IIS Registration Tool (aspnet_regiis.exe).

Encrypting a Physical Directory

To encrypt a specific section using physical directory paths:

aspnet_regiis -pef "connectionStrings" "C:\inetpub\wwwroot\MyApplication" -prov "RsaProtectedConfigurationProvider"

• -pef specifies the section to encrypt and the physical path to the application root.
• -prov specifies the provider to use (optional if using the default RSA provider).

Decrypting a Physical Directory

To reverse the encryption and view the original XML configuration:

aspnet_regiis -pdf "connectionStrings" "C:\inetpub\wwwroot\MyApplication"

Programmatic Encryption

You can also encrypt configuration sections directly in C# code using the System.Configuration namespace:

using System.Configuration;
using System.Web.Configuration;

Configuration config = WebConfigurationManager.OpenWebConfiguration("~");
ConfigurationSection section = config.GetSection("connectionStrings");

if (!section.SectionInformation.IsProtected)
{
    section.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider");
    config.Save();
}

How Transparent Decryption Works at Runtime

One of the main strengths of .NET’s protected configuration model is transparent decryption. You do not need to write custom decryption logic or alter your application’s data access code.

When the application accesses a configuration section via ConfigurationManager.ConnectionStrings or WebConfigurationManager.AppSettings, the .NET runtime: 1. Detects the <EncryptedData> tag within the requested XML node. 2. Identifies the designated provider declared in the file’s <configProtectedData> section. 3. Retrieves the appropriate key (from DPAPI or the local RSA container). 4. Decrypts the XML in-memory and returns the plaintext values to the caller.

The decrypted data exists only in memory for the duration of the request lifecycle, ensuring that the underlying file on disk remains protected.

Multi-Server and Web Farm Deployments

When using the RsaProtectedConfigurationProvider across a cluster of servers, each server must have access to the same RSA key container. The operational workflow involves:

1. Creating a custom RSA key container using the aspnet_regiis -pc command on a primary machine.
2. Exporting the key pair (including the private key) to an XML file using aspnet_regiis -px.
3. Importing the key container onto each server in the web farm using aspnet_regiis -pi.
4. Granting read permissions to the application pool identity (e.g., IIS_IUSRS or NETWORK SERVICE) using aspnet_regiis -pa so the running worker process can decrypt the configuration at runtime.