I am suddenly unable to access our passbolt instance with the following error shown in the browser:
Could not verify server key. Unable to encrypt the verify token. Error encrypting message: Could not find valid key packet for encryption in key […]
Upon running the health check on the command line, I came accross this error:
[FAIL] The server public key defined in the config/passbolt.php is not in the keyring
[HELP] Import the private server key in the keyring of the webserver user.
[HELP] you can try:
[HELP] sudo su -s /bin/bash -c "gpg --home /…/.gnupg --import /…/httpdocs/config/gpg/private.key" passbolt
However, after running the import, it just says:
gpg: key ABC12345: already in secret keyring
gpg: Total number processed: 1
gpg: secret keys read: 1
gpg: secret keys unchanged: 1
To investigate this further, I executed gpg --list-keys --fingerprint and noticed that that key had expired on the 30th of January:
Is this the reason why passbolt is reporting “The server public key defined in the config/passbolt.php is not in the keyring”? If so - how does one handle expired keys? And why did it expire in the first place?
You will need to replace the gpg key (create a new one or remove the expiration of the first one). Then all you users will need to perform a “recover” operation in order to approve the new key. We are aware that this not convenient, but unfortunately that is the only option at the moment.
By default to my knowledge the keys do not expire in GnuPG, so you or your colleagues must have set an expiration date.
Well, it must have been me . Though I was not aware of it. I thought I followed the default installation procedure back then… it was still in 1.x times.
I followed this tutorial on how to remove the expiration date of a key. However, I am unsure about the last step:
now you can update the public key that is stored on the various keyservers. To achieve this use the following command. In this example, the keyserver at pgp.mit.edu is used. $ gpg --keyserver pgp.mit.edu --send-keys B989893B
Ok, thank you :). After removing the expiration date the healtcheck does not report any problems anymore.
However, I am still unable to do an account recovery. After providing my private key it immediately says
This key doesn’t match any account.
But I am 100% sure that the private key I provided is in fact the private key of my account. I have used it recently (before 2019-01-30) to access my account from a different machine.
Can you try to delete the browser extension and reinstall it again to see if it works?
There might be a regression that prevent this to work (like the old server key is still being used even though you accepted a new one).