I’m using Passbolt for a while now and and it was working fine so far. The users that have their accounts restored in their browsers are able to login and interact with Passbolt perfectly fine.
The issue starts when a user is trying to restore the account. After arriving to the step where the user has to paste the private key, when pressing “Next” the process fails claiming that “This key doesn’t match any account.”. In the Debug console in Chrome and Firefox it shows a “undefined” exception in some promise.
setup.html:1 Uncaught (in promise) undefined
(anonymous) @ setup.js:285
dispatch @ jquery.js:5429
elemData.handle @ jquery.js:5233
In the “Network” tab I cannot see any requests made when pressing “Next”, but on the server logs I can see that a request is made and succeeds with a 200 response:
"GET /auth/is-authenticated.json HTTP/2.0" 200 213 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44"
Anybody has an idea what is going on? All healthchecks seems to be passing in Passbolt. Nothing on the Server has changed. The only change performed a few weeks ago was disabling the expiration date on the root “entry?” in the gnupg file as it had expired.
The only change performed a few weeks ago was disabling the expiration date on the root “entry?” in the gnupg file as it had expired.
Did you also export that new updated server key on file in
config/gpg or did you change it only in Gnupg?
I only changed it in Gnupg.
I just ran this, which indeed produced different keys (The XXXX being the fingerprint of the root/first entry. I’m using the fingerprint rather than the email due to the root entry and one of the users having the same email).
gpg --armor --export-secret-keys “XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX” > ~/passbolt/config/gpg/serverkey_private.asc
gpg --armor --export “XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX” > ~/passbolt/config/gpg/serverkey.asc
It still shows “This key doesn’t match any account”.
One thing that I was able to observe is that every user in exception to the root account shows up as "uid [ unknown] ". Is that normal? The root user shows up as “[ultimate]”.
How is it possible that the users that are already restored previously are working?
Running when running "gpg --armor --armor --export " to get the user’s public key, shows a different Key Block from what can be seen as Public Key from the “users” admin page with the already logged in users. Is that normal?
This seems to be exactly the same issue as I have (There is no solution it seems in that thread): Could not verify server key - did the key expire?
The recovery process uses the gpg auth verify step to check whether the user exist. That step has been made non blocking for the login process, which explains why your user can still login even though the key is expired but recovery cannot be completed.
I’m not sure which user key you are referring to. The user key is not the issue, it is most likely the server key the culprid. You need to make sure:
- The server key is not expired in the keyring.
- The server public key version that is not expired is exported in the config/gpg directory in place of the expired key that was (and most likely is still) being served to the users.
- That the expired server public key is replaced from the users config (e.g. in the user browser local storage), either via a recovery or via the new “the key have been updated” screen on the login (all users should see it, if they don’t the server key is still the same).
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.