Moving User Public Key to common folder for IIS to work

I generated a private/public key and it is working fine when encrypting/decrypting files through the console application. But the same is not working when using a Web API with IIS.

After googling, it is to be found that I need to move the keyring files from the user profile directory to c:\gnupg.

I could find lot of files in user profile directory. What are the files needs to be moved from here?

Solution

The GnuPG Home Directory

GnuPG operates within per-system-user GnuPG home directories (~/.gnupg/ on unixoid systems, somewhere in %USER%\AppData for Windows-based systems). GnuPG is very picky about tight permissions on this folder and it's contents, and will by default deny operation or at least warn if other system users can access those files.

The most important files are gpg.conf (holding GnuPG's configuration), pubring.gpg or pubring.kbx holding public keys and secring.gpg holding private keys (this file is merged into the pubring for GnuPG starting with version 2.1). The trustdb.gpg holds trust information.

The other files are mostly implementation-specific or serve the communication with the gpg-agent and are not of importance for you unless you do advanced GnuPG operations.

Migrating Keys to the Service User's GnuPG Home Directory

If you develop services under one user, and run them under another, you will have to import keys again. The best way to do so is exporting the keys, and importing them again in the other user account.

Export the public key
```
gpg --export [key-id] > public-key.gpg
```

Export the secret key

gpg --export-secret-keys [key-id] > secret-key.gpg

Switch the user context through for example
```
su - [username]
```
on unixoid systems or by opening a new command prompt for this user (right-click, "Run as")

Importing secret and public keys again

gpg --import secret-key.gpg
gpg --import public-key.gpg

You might have to add further keys, provide trust and so on as usual, depending on your individual requirements.

Changing the GnuPG Home Directory Location

You can also switch to another GnuPG home directory for your application. This might be reasonable to keep application data together, but don't put it in C:\gnupg, which is a horrible location for application data. Put the folder wherever your application stores it's application data.

Changing the home directory works through the --homedir option or the GNUPGHOME environment variable. You should still maintain separate home directories for local operations, test and production environments -- on one hand, you mitigate all permission issues but not tampering with them and stick with GnuPG's defaults, on the other hand prevent issues with interleaving personal GnuPG usage and your application. Having production keys in your test environment would be an indication of severe problems with your development and release practice, anyway.