What causes "The SSO setting cannot be decrypted." in passbolt/passbolt_api?

Restore the original server key (fingerprint + private key + passphrase) that encrypted the data, then retry.

passbolt/passbolt_api · critical · InternalErrorException

The SSO setting cannot be decrypted.

Error message

The SSO setting cannot be decrypted.

What it means

decrypt() successfully set up the key but the call to $gpg->decrypt($data) on the stored, encrypted SSO settings payload failed; the exception is wrapped as InternalErrorException 'The SSO setting cannot be decrypted.' This means the data column cannot be turned back into plaintext JSON with the currently configured server key.

Solutions

Restore the original server key (fingerprint + private key + passphrase) that encrypted the data, then retry.
Check the appended previous exception message from gnupg for the precise decrypt failure cause.
Delete and re-create the SSO settings if the data is unrecoverable (settings can be re-entered).
Verify no DB migration/import altered the data column encoding (use binary-safe transport, e.g. --hex-blob for mysqldump).

Defensive patterns

Strategy: try-catch

Try / catch

try { $dto = $service->getByIdOrFail($id, true); } catch (InternalErrorException $e) { if (str_contains($e->getMessage(), 'cannot be decrypted')) { // recover old server key or re-create settings } }

Prevention

Always migrate the GPG server key when moving/restoring to another host
Back up the server key keyring together with the database
Avoid charset-converting dumps containing encrypted binary data (use --hex-blob)
Re-create SSO settings if the original key is lost

When it happens

Trigger: The sso_settings.data was encrypted with a different server key than the one now configured (e.g. server key rotated or host migrated); the encrypted blob is corrupted or truncated; database content mangled by a bad migration/import (encoding issues).

Common situations: Restoring a database backup onto a server whose OpenPGP server key differs from the one that encrypted the rows; upgrading/moving passbolt without migrating the server key keyring; charset conversion corrupting binary data in the DB.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17). Data as JSON: /api/errors/bcdc4df611a6c6c8. Report an issue: GitHub.

Appendix: source

Thrown at plugins/PassboltEe/Sso/src/Service/SsoSettings/SsoSettingsGetService.php:166

        $passphrase = Configure::read('passbolt.gpg.serverKey.passphrase');

        try {
            $gpg->setDecryptKeyFromFingerprint($fingerprint, $passphrase);
        } catch (Exception $exception) {
            try {
                $gpg->importServerKeyInKeyring();
                $gpg->setDecryptKeyFromFingerprint($fingerprint, $passphrase);
            } catch (Exception $exception) {
                $msg = __('The OpenPGP server key defined in the config cannot be used to decrypt.') . ' ';
                $msg .= $exception->getMessage();
                throw new InternalErrorException($msg, 500, $exception);
            }
        }

        try {
            $decryptedData = $gpg->decrypt($data);
        } catch (Exception $exception) {
            throw new InternalErrorException(__('The SSO setting cannot be decrypted.'), 500, $exception);
        }

        $decodedData = json_decode($decryptedData, true);
        if (!isset($decodedData) || !is_array($decodedData)) {
            throw new InternalErrorException(__('The SSO setting cannot be decoded.'));
        }

        return $decodedData;
    }
}

View on GitHub (pinned to 31c1bbc10f)