The RSA key container could not be opened. Windows Server 2008 R2

I am setting up a second asp.net site on our Windows 2008 R2 server. We use a RSA Key Container to encrypt our connection strings. I created a new Application Pool with all the same settings as our Default Application Pool that is supporting our current site, including using the same user account for the identity. When I try to access the new site I get the following error: The RSA key container could not be opened

If I change the new website to use our Default Application Pool it works. So I try and give the user account in the new Application Pool access to the RSA Key Container using the following command in an Administrator Command Prompt:

aspnet_regiis -pa "KeyContainerName" "dmz\UserName"

I get the following error: The RSA key container was not found.

I run the following command to install the key container:

aspnet_regiis -pi "KeyContainerName" "c:\keys.xml"

I get the following error: Object already exists

I try and run the following command to delete the key container:

aspnet_regiis -pz "KeyContainerName"

I get this error: The RSA key container was not found. Failed!

So I am completely baffled, one command tells me it already exists which makes sense because I know our one website is using it, but when I tried to delete it tells me it doesn't exist. It works for one app pool but not for a new app pool using the exact same identity? I did this exact same setup on 12 other servers and they all worked fine.

Solution 1:

I have had something similar.

If the account you are using does not have permission to the key container then when you try to grant permission to it (aspnet_regiis -pa "KeyContainerName" "dmz\UserName") you get the Key Container not found error. However the key does exist; hence, the error when you try to re-create it.

This would mean that the key was created by a different account.

If you can log on as that account you can then do

aspnet_regiis -pa "KeyContainerName" "dmz\YourUserName" -full

to grant your own account control of the key. I would suggest setting up a KeyAdministrators NT group and granting access to that and getting yourself in the group.

Solution 2:

"I did the same thing on 12 other servers and it worked fine"

Well:

Reimage the server or start again. Something is clearly different about this one, even at this early stage.

If you're doing exactly the same thing (incidentaly, why isn't it scripted?) on every server, and they've all behaved identically and were all configured identically but this one's somehow different, things will only get worse from here.