Unable to Restore after updating server key expiry

Checklist
[ x ] I have read intro post: About the Installation Issues category
[ x ] I have read the tutorials, help and searched for similar issues
[ x ] I provide relevant information about my server (component names and versions, etc.)
[ x ] I provide a copy of my logs and healthcheck
[ x ] I describe the steps I have taken to trouble shoot the problem
[ x ] I describe the steps on how to reproduce the issue

We have been using passbolt for a number of years. The installation is a source installation, and it runs alongside a number of other open source self hosted sites.

Recently, our installation complained that the server GPG key expired. OK, lets update the expiry to 0 and kick things back into production.

We updated the server key to remove this expiration, but now the site keeps returning the following –

  • The OpenGPG sever defined in the config cannot be used to decrypt. Could not import key.

    This is displayed on browsers that have the plugin installed.

  • I have also tried removing the plugin, and tried recovering accounts (3 in total) using respective private keys.

    When this is done, the plugin returns that the provided key does not belong to any user.

Installation details;

  • Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux
  • Installed to /home/passbolt/passbolt_api
  • Hosted using a named virtual host on apache v2.4
  • GNU keyring installed to /home/passbolt/.gnupg

I have also tried to generate a complete new server key. The plugin responds correctly with key change warning, however, we are still at the same place. In terms of not being able to use the key.

Something strange I did notice…

All the GPG keys have always belonged to the passbolt user we have setup, who belongs to the www-data group.

drwx------ 4 passbolt www-data 4096 May 22 18:38 .gnupg

  • I can view keys by (I see server and user keys) sudo -u passbolt -H gpg --list-keys.
  • I cant view keys by sudo -u www-data -H gpg --list-keys. This returns error gpg: Fatal: can't create directory '/var/opt/gitlab/nginx/.gnupg': Permission denied
  • We have also tried setting user/group to www-data

I dont know if the gitlab installation is stomping on the GNU home directory for www-data?
The keyring defined in passbolt_api/config/passbolt.php is /home/passbolt/.gnupg, with putenv defined as true.

Installation has been working flawlessly (up until key expiry), this means we have a lot of critical information sitting on this server that we need to access…

Any clues on things I can try? Nothing we are trying or reading online seems to make a difference to our installation.
Any more information I can post to help?
Is there a way to pass --homedir to the gpg command, is it correct to assume that this is what keyring definition in the configuration file does?

Hello @juansta,

It is possible to pass the gnupg home to a gpg command with an environment variable as following:

GNUPGHOME=/home/www-data/.gnupg gpg COMMAND_TO_EXECUTE

When updating the server gpg keys, you have to be ensure that:

  1. Passbolt can access the new keys. Usually they are located in config/gpg but it might vary if you have updated the gpg section of the passbolt.php config file. Ensure that you have updated the public and private key after updating the expiry.

  2. The new key should be in the gpg keyring of the webserver user. As I presume you didn’t update the expiry of the key directly in the webserver user keyring, then you need to import it into it.

GNUPGHOME=/home/www-data/.gnupg gpg --import KEY_PATH

Check that the key has been updated in the keyring

GNUPGHOME=/home/www-data/.gnupg gpg --list-keys

As the fingerprint of they key didn’t change, if gpg didn’t didn’t update the key, then you can delete the keyring and start with a new one (it’s the quickest):

rm -fr /home/www-data/.gnupg
GNUPGHOME=/home/www-data/.gnupg gpg --import KEY_PATH
  1. As the server public key is stored in your users plugins local storage and you just changed it, your users will have to update their local configuration. On the login page of passbolt, a form will propose them to update the server key, they will have to accept the change. Note that this form is released with the latest version of the extension v2.12.3, which has been published today, and so it might not have been deployed yet on all your users browser. You can of course force the update of the extension if you need it.

I hope it will help,
Thanks for using passbolt

Just to add to what cedric says you can specify the home directory also using --home option:

sudo su -s /bin/bash -c "gpg --list-keys --home=/home/www-data/.gnupg" www-data

Thanks for the very prompt response!

The key step we were missing was being able to define --home when preparing the keyring for www-data. We were also running the healthcheck as the passbolt user, not www-data.

We were hesitant to just delete the keyring altogether, but that was definitely the quickest way out.

Just a few more questions (to understand what the keyring does):

  • We were hesitant to change the server key for a brand new one, thinking this would hinder the ability to decode passwords. Obviously this isn’t the case?
  • We were hesitant to delete the keyring altogether, thinking this would stop the ability for existing users to log in. Obviously this isn’t the case? As existing users recover their accounts, the keyring is populated with required keys?