Encrypting sensitive information in configuration files seems rather obvious when working with web development. In my current project I got a chance to implement the use of ImageVault 4 in our EPiServer 8 website, and started looking into how I would go about encrypting the connectionStrings file.
RSA encryption on ImageVault Core’s connectionStrings
For a website’s connectionStrings you’d normally just have to run something like the following on the server that the site has been deployed on.
# Encrypt: aspnet_regiis.exe -pef 'connectionStrings' 'C:\Inetpub\wwwroot\YourWebSite' -prov 'RSAProtectedConfigurationProvider' # Decrypt: aspnet_regiis.exe -pdf 'connectionStrings' 'C:\Inetpub\wwwroot\YourWebSite'
However, if you try this on the ImageVault Core binary directory where your connectionStrings resides, you’d find that nothing happens.
# Encrypt: aspnet_regiis.exe -pef 'connectionStrings' 'C:\ImageVault\Core\MyInstance\bin' -prov 'RSAProtectedConfigurationProvider'
This is because the path argument is actually the path to the directory containing your web.config file, and not the ImageVault Core ImageVault.Core.Host.exe.config; aspnet_regiis.exe expects the configuration file with the connectionStrings settings to be called web.config.
The (somewhat ugly) trick getting this to work is to temporarily rename ImageVault.Core.Host.exe.config (or app.config as well if that’s what you got) to web.config, run the encryption, and then rename it back to the original filename. In my current project we keep server specific MSBuild configuration transforms for not just the website, but for ImageVault Core and ImageVault Ui as well; redeploying everything every time we release new code. This leads to the following parts of a module attached to our deploy script.
$originalIVConfigName = "$imageVaultCoreConfigPath\ImageVault.Core.Host.exe.config" $temporaryIVConfigName = "$imageVaultCoreConfigPath\Web.config" Move-Item $originalIVConfigName $temporaryIVConfigName -Force Write-Host "Encrypting $imageVaultCoreConfigPath\connectionStrings.config" Invoke-Expression "$aspnetRegIIS -pef 'connectionStrings' $imageVaultCoreConfigPath -prov 'RSAProtectedConfigurationProvider'" Write-Host " - Done" -ForegroundColor Green Move-Item $temporaryIVConfigName $originalIVConfigName -Force
Once we run this script, the connectionStrings section will be encrypted. Note that the connectionStrings is extracted into a separate file.
The ImageVault Core Service (MyInstance) will not start with encrypted connectionStrings
An issue that you may run into encrypting ImageVault Core’s connectionStrings is that the ImageVault Core Service for your instance won’t start up again after you try to restart it. Meriwork‘s Robert Blomqvist pointed me in the right direction when I ran into this setting it up for my current client. The problem is that the user running the service (the Network Service user by default, but could be whatever user you set up) does not have the proper access rights to decrypt the encrypted section, while the ApplicationPoolIdentity does.
The following command will grant read access to the RSA Key Container for the specified user, thus resolving the issue.
# AD user account aspnet_regiis.exe -pa "NetFrameworkConfigurationKey" "MyAD\MyUserName" # Default user Network Service aspnet_regiis.exe -pa "NetFrameworkConfigurationKey" "networkservice"
