aspnet/DataProtection

Move keys from registry to new system

strohhut opened this issue · 6 comments

On my old machine DataProtection created two keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0\AutoGenKeys\S[...]\DataProtection that are encrypted with DPAPI. I guess the encryption happens on behalf of the app pool user (IIS AppPool\MyAppPoolName).

Now I want to move the website to a new machine and it would be nice if users are still logged in. I exported the DataProtection node with regedit and imported it to the new machine. The problem is that on the new machine regedit shows only the default key after importing. The two actual keys are missing.

The website that created the two keys has UseCookieAuthentication in Startup.cs. I leave the default settings for the DataProtectionProvider.

Is it possible to decrypt the keys on the old machine and then import them on the new machine?

As far as I understand Provision-AutoGenKeys.ps1 enables an app pool account to store keys in the registry but doesn't help with exporting.

Basically you can't, because DPAPI keys don't get exported, that's kind of their point :)

I guess you could write some code to manually decrypt, and then reencrypt on a new machine, but it's not something we support. You could look at persisting to the file system, and protecting with an X509 certificate. This would enable copying, as long as you bring the certificate over.

If this is not supported then it might be helpful to add a warning somewhere that the default settings limit the portability of the keys. At least for me this wasn't obvious.

Of course the best solution would be a tutorial on how to move encrypted keys.

@strohhut I second that. I am in similar situation.. Pls see my comment on the other thread https://github.com/aspnet/dataprotection/issues/120#issuecomment-339412107

Moving keys that are encrypted using the default mechanism is probably something that will never be supported / documented because of how fragile and error-prone it is. The easiest and most fool-proof way to migrate a live web app would be what @blowdart suggests: configure the Data Protection system to use the file system as the key repository, and also configure it to use an X.509 certificate to protect keys at rest. You can even do this using a console application and watch the key files get dropped on disk. Then change your web app's startup config to use the same repository / protection mechanism. After a few days (default 48 hours) the key rotation policy will kick in and the web application will start using the new keys on disk rather than the old keys from the registry. (The old keys will still be able to decrypt existing auth tokens, but they won't be used to issue new auth tokens.) Wait a few more days to make sure that all existing logged-on users have had their auth tokens refreshed. Then you can move the web application - keys and all - to the new machine. You'll lose the ability to decrypt with the old keys, but this shouldn't result in service interruption since all logged-on users should have had their auth tokens refreshed over the waiting period.

This issue was moved to dotnet/aspnetcore#2515