Metadata key could not be shared when activating account

Community Feedback
1

Hello,
I have an issue while using Passbolt. I don’t think there is anything wrong with the application, I think there is an issue with my data or the way I’m using Passbolt. I’ve searched here and found nothing and I’m unable to figure out how to fix it so I’m hoping someone here can help me.

The issue is after I add a new user account, when the new user activates their account the application logs the following error message to /var/log/passbolt/error.log:
2025-07-28 20:51:40 error: The metadata private key cleartext data is not valid. Metadata key could not be shared with user id: 98971b6a-f4de-4aee-8ce2-e4e03a33f83d.

In the GUI, the user’s information shows the metadata keys are missing

test_user
test_user264×334 10.7 KB

Everything else in the application seems to work fine. Existing passwords decrypt and you can add new password entries. The app and db health checks pass. This issue did not exist on the old server. I had added a new user just a few days before the server failed and they activated with no issues.

Here is some version information:
-Passbolt v5.2.0 server on Rocky Linux 8.10
-Browser is Chrome with Passbolt extension 5.3.2
-MariaDB version is 10.3.39
-PHP version is 8.2.29
-nginx version is 1.14.1

Background Information:
I had to rebuild our Passbolt server and restore from backups. I had to use a different server, with a different hostname and IP and it’s own SSL cert.

To setup the new server I install and configure Passbolt following standard procedure from passbolt.com. Next I stop nginx and php-fpm service as well as terminate the process gpg-agent so that there are no processes running for the nginx user.

Then I do the following to prepare the new server to use the production database.
1 - I copy /etc/passbolt/passbolt.php from the primary server backup and replace the same on the new server. I edit fullBaseUrl and change the FQDN to match the new server.

2 - I copy /etc/passbolt/gpg/serverkey.asc and serverkey_private.asc from the primary server backup and replace the same on the new server.

3 - I copy the directory /var/lib/passbolt/.gnupg from the primary server and replace the same on the new server.

4 - I load a backup of the primary database into the new server

5 - I reboot the server

I used this same method with version 4 of Passbolt and it worked but it no longer does. I’m not suggesting anything is wrong with Passbolt, I’m 99.9% sure it’s my process or data that is broke.

Does anyone know what is causing my issue, or how to fix it?

Thanks for taking the time to read this post!!

2

Hello @skystar thanks a lot for all the details, it helps a lot to reproduce the issues on our end.While this is an expected behavior when you are changing the domain of your API, prior to share a new metadata key with the user, the API ensure that the domain when the metadata key has been created remain the same which seems not to be the case here.

From there, you can share the metadata key via the users workspace after selecting the user you should see a dedicated button to share the metadata key in the action bar.

From the time being you can disable the security check on the API side to allow the server to share the metadataKey after the user setup. This can be done by adding passbolt.security.checkDomainMismatch in /etc/passbolt/passbolt.php:

(...)
  'passbolt' => [
  (...)
    'security' => [
      'checkDomainMismatch' => false,
    ],
  (...)
],

In future releases, we will offer a mechanism in order to rotate the metadataKey that will solve this issues.

Best regards,

3 Likes
3

Hello @antony Thank you very much for taking time out of your busy day to respond to my post. Not only did you provide the solution to my issue, you explained why it was happening. I really appreciate your help resolving my issue! Thank you!!

3 Likes