Can Passbolt CE run with FIPS mode enabled? Issues after enabling FIPS on an existing install

Hello,

I’m looking for guidance on whether Passbolt CE is expected to work with FIPS mode enabled, or if this is a known limitation.

We have an existing Passbolt CE installation that was previously running without FIPS enabled and was working as expected. As part of recent security hardening, FIPS mode was enabled at the operating system level after Passbolt was already installed.

Shortly after enabling FIPS, we began experiencing the following issues:

• Existing users started receiving an “internal error has occurred” message during login. (Some users are still able to log in without any issues,)
• Passbolt logs show encrypt-sign failed errors during /auth/login.json requests
• Account recovery appears to complete successfully, but login still fails afterward
• Attempting to create new users now fails with an error stating that the uploaded OpenPGP public key cannot be used to encrypt

We have validated the following:

• GnuPG keyring location, ownership, and permissions are correct
• Keys are not expired and are intact
• The issue is reproducible across browsers
• Restoring the Passbolt instance to a separate server with FIPS disabled immediately resolves both login and account creation issues

Based on our testing, this appears to be related to FIPS enforcement blocking non-FIPS OpenPGP algorithms.

My questions are:

• Is Passbolt CE officially supported or expected to work with FIPS mode enabled?
• If so, are there documented requirements or limitations around OpenPGP key algorithms (for example, requiring RSA keys only)?
• Is enabling FIPS after an existing Passbolt deployment a supported configuration, or would this require a full re-keying of users or a different deployment model?

Any guidance from the Passbolt team or others who have attempted to run Passbolt CE in a FIPS-enabled environment would be greatly appreciated.

Thank you.

1 Like

I wanted to follow up and close the loop on this. I was able to confirm a working solution.

The workaround is to manually generate FIPS-compatible RSA OpenPGP keys and import them into the Passbolt browser extension, rather than relying on the extension’s automatic key generation.

This approach works well for new users . For existing users whose previously generated keys are no longer usable under FIPS, the options are more limited in the Community Edition. At this point, the only viable path appears to be restoring a backup of the Passbolt server to a non-FIPS host so users can log in and export any privately stored passwords.

Once those passwords are exported, the user account can be deleted on the FIPS-compliant server, recreated using the new RSA keys, and the private passwords re-imported. Most organization passwords are already shared via groups, which makes it relatively straightforward to restore access to previously shared credentials through group membership.

The documentation that helped point me in the right direction is here:
https://www.passbolt.com/docs/admin/faq/generate-openpgp-key/

Thanks to everyone who weighed in. Hopefully this helps anyone else running Passbolt CE in a FIPS-enforced environment.

1 Like

G’day Kevin. I was just composing this response to your first message :slight_smile:

If you set the User Key Policy to RSA and 3072 in passbolt.php you will be able to create new users.
Your existing users with ECC keys should be fine. From the customers I’ve seen it’s just new users.

I won’t give you a more ‘official’ response as one of the complications of RSA keys is that they make the encrypted payloads larger than than using ECC and that has potential challenges around performance with passbolt instances that have a lot of users/sharing/resources.

https://www.passbolt.com/docs/hosting/configure/environment-reference/#user-key-policies-configuration

    'passbolt' => [
        'gpg' => [
            // Main server key.
            'serverKey' => [
                // Server private key fingerprint.
                'fingerprint' => '<your_server_key_fingerprint>',
                'public' => CONFIG . DS . 'gpg' . DS . 'serverkey.asc',
                'private' => CONFIG . DS . 'gpg' . DS . 'serverkey_private.asc',
            ],
        ],
        'plugins' => [
            'userKeyPolicies' => [
                'enabled' => true,
                'preferred_key_type' => 'rsa',  // Set the key type and size
                'preferred_key_size' => '3072', // Don't leave this out or you get ECC
            ],
        ],
        'ssl' => [
            'force' => false,
        ]
    ],
];

Cheers
Gareth

To add to what @gyaresu said, existing users will work fine only if the non FIPS compliant keys were already added in the gnupg keyring. The key import is the step that breaks when enabling FIPS mode when using ECC keys (due to key signature algorithm). So the best course of action for long term stability is to migrate the users that do not have RSA keys to that instead of ECC keys. Otherwise you may run into issues if the gnupg keyring is flushed (for example when deploying passbolt on a new server).

1 Like

Thank you for the explanation. I added this to the configuration and can confirm it is now generating RSA 3072 keys when new users are created.

What initially threw me off is that the issue first appeared with a single user who suddenly could no longer log in. At this point, my assumption is that this user had not logged in during the window between when the Passbolt instance was migrated to the new server and when FIPS mode was later enabled.

Other users who still had existing ECC keys and had already logged in during that time appear to have remained unaffected and are still able to authenticate successfully.

One follow-up question: for an existing user who currently has an ECC key and is still able to log in successfully, is there a supported way for them to rotate their key to a newly generated RSA key now that the passbolt.php configuration has been updated? Specifically, would changing the passphrase under Manage Account > Passphrase trigger generation of a new RSA key, or is key regeneration handled separately?

Thanks again for the help.

Thank you for the follow up explanation @remy. Is there a way to migrate users from using a ECC to a RSA key other than to delete the account and re-add it?