Could not verify server key - did the key expire?

Hello there,

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:

/[…]/.gnupg/pubring.gpg
------------------------------------------------------------
pub   2048R/ABC12345 2018-01-30 [expired: 2019-01-30]
      Key fingerprint = […]
uid                  […]

[…]

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?

hello,

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 :smiley: . 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

Is this required for the server key of passbolt?

No it shouldn’t be. Passbolt does not rely on keyservers for trust at the moment.

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.

There is another thread about such a problem: Cannot recover user due to 'Key doesn't match any account' after server move
However, I don’t really understand the technical background in this case. Other than the key expiring, nothing changed on the server.

Hello,

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).

I tried that, unfortunately it did not work. We also tried with the private keys of other users in our company - none of them worked :confused:

Can you send us an email at contact@passbolt.com, we can schedule a call and check together.

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.