I’m having the same problem.
Using Firefox 89.01 on Ubuntu. Chromium works fine
@jstuck can you open a new issue, with the details of the server, browser and error? Since upgrading firefox didn’t solve your issue then it’s not exactly the same parameters, so we consider it to be a separate issue.
hi @jstuck another user reported similar issue with firefox using multi-account container plugin. Could it be your issue?
Same issue here. After activating the account, on the last step this error appears. But the user works just fine afterwards.
hello
i have the same issue with firefox browser in private windows, working fine with standard window
i have :
> sudo su -s /bin/bash -c "/usr/share/php/passbolt/bin/cake passbolt healthcheck" www-data
>
> ____ __ ____
> / __ \____ _____ ____/ /_ ____ / / /_
> / /_/ / __ `/ ___/ ___/ __ \/ __ \/ / __/
> / ____/ /_/ (__ |__ ) /_/ / /_/ / / /
> /_/ \__,_/____/____/_.___/\____/_/\__/
>
> Open source password manager for teams
> -------------------------------------------------------------------------------
> Healthcheck shell
> -------------------------------------------------------------------------------
>
> Environment
>
> [PASS] PHP version 8.2.7.
> [PASS] PCRE compiled with unicode support.
> [PASS] The temporary directory and its content are writable and not executable.
> [PASS] The logs directory and its content are writable.
> [PASS] GD or Imagick extension is installed.
> [PASS] Intl extension is installed.
> [PASS] Mbstring extension is installed.
>
> Config files
>
> [PASS] The application config file is present
> [PASS] The passbolt config file is present
>
> Core config
>
> [PASS] Debug mode is off.
> [PASS] Cache is working.
> [PASS] Unique value set for security.salt
> [PASS] Full base url is set to https://passbolt.pra.rip
> [PASS] App.fullBaseUrl validation OK.
> [PASS] /healthcheck/status is reachable.
>
> SSL Certificate
>
> [PASS] SSL peer certificate validates
> [PASS] Hostname is matching in SSL certificate.
> [PASS] Not using a self-signed certificate
>
> Database
>
> [PASS] The application is able to connect to the database
> [PASS] 30 tables found
> [PASS] Some default content is present
> [PASS] The database schema up to date.
>
> GPG Configuration
>
> [PASS] PHP GPG Module is installed and loaded.
> [PASS] The environment variable GNUPGHOME is set to /var/lib/passbolt/.gnupg.
> [PASS] The directory /var/lib/passbolt/.gnupg containing the keyring is writable by the webserver user.
> [PASS] The server OpenPGP key is not the default one
> [PASS] The public key file is defined in /etc/passbolt/passbolt.php and readable.
> [PASS] The private key file is defined in /etc/passbolt/passbolt.php and readable.
> [PASS] The server key fingerprint matches the one defined in /etc/passbolt/passbolt.php.
> [PASS] The server public key defined in the /etc/passbolt/passbolt.php (or environment variables) is in the keyring.
> [PASS] There is a valid email id defined for the server key.
> [PASS] The public key can be used to encrypt a message.
> [PASS] The private key can be used to sign a message.
> [PASS] The public and private keys can be used to encrypt and sign a message.
> [PASS] The private key can be used to decrypt a message.
> [PASS] The private key can be used to decrypt and verify a message.
> [PASS] The public key can be used to verify a signature.
> [PASS] The server public key format is Gopengpg compatible.
> [PASS] The server private key format is Gopengpg compatible.
>
> Application configuration
>
> [PASS] Using latest passbolt version (4.0.2).
> [PASS] Passbolt is configured to force SSL use.
> [PASS] App.fullBaseUrl is set to HTTPS.
> [PASS] Selenium API endpoints are disabled.
> [PASS] Search engine robots are told not to index content.
> [INFO] The Self Registration plugin is enabled.
> [INFO] Registration is closed, only administrators can add users.
> [PASS] The deprecated self registration public setting was not found in /etc/passbolt/passbolt.php.
> [WARN] Host availability checking is disabled.
> [HELP] Make sure this instance is not publicly available on the internet.
> [HELP] Or set the PASSBOLT_EMAIL_VALIDATE_MX environment variable to true.
> [HELP] Or set passbolt.email.validate.mx to true in /etc/passbolt/passbolt.php.
> [PASS] Serving the compiled version of the javascript app.
> [WARN] Some email notifications are disabled by the administrator.
>
> JWT Authentication
>
> [PASS] The JWT Authentication plugin is enabled
> [PASS] The /etc/passbolt/jwt/ directory is not writable.
> [PASS] A valid JWT key pair was found
>
> SMTP Settings
>
> [PASS] The SMTP Settings plugin is enabled.
> [PASS] SMTP Settings coherent. You may send a test email to validate them.
> [PASS] The SMTP Settings source is: database.
> [WARN] The SMTP Settings plugin endpoints are enabled.
> [HELP] It is recommended to disable the plugin endpoints.
> [HELP] Set the PASSBOLT_SECURITY_SMTP_SETTINGS_ENDPOINTS_DISABLED environment variable to true.
> [HELP] Or set passbolt.security.smtpSettings.endpointsDisabled to true in /etc/passbolt/passbolt.php.
>
> [PASS] No error found. Nice one sparky!
pra
This error seems to pop up from time to time and there doesn’t seem to be much knowledge/content around the specific reason(s) for this error. Tried re-installing multiple times and spent numerous hours trying to determine the nature of the issue - to no avail. Did this on Debian with the install script and it completed without issue. Health check passes, email test (during install) works. Yet it reliably fails with the gpgauth error. That’s under Debian 12.1 using a fresh install (no modifications and following the installation instructions on passbolt’s site). Getting a bit ridiculous as there’s so little around x-gpgauth-authenticated to help one determine the real issue. There’s some postings around ‘check the headers’, but that begs the question of why isn’t it “just working” from a vanilla ISO install of Debian and following the instructions for a dedicated install? The only additional aspect is that for security reasons, the browser is required to be LibreWolf which supports the passbolt extension (as LibreWold is FF with security enhancement). FWIW - Tested on FF which also fails. Both browsers are the latest version.
Sadly, while there appears to be a lot to like about passbolt, trying to get a POC running for an instance where it must be on-prem - just simply seems mission impossible. One question I have is, was the installation tested using a Mac for installation (latest MacOS), FF/Librewolf browser (latest version/no enabled extensions except passbolt) and doing so with a fresh install of the latest version of Debian? In theory, that should just work and without issue as there would be no customizations to the instance except for passbolt requirements.
hey @doubts welcome to the forum. For this particular error message:
x-gpgauth-authenticated should be set to false during stage1
We’ve seen that this is often caused by a time sync issue. So, you’ll want to make sure NTP is running correctly(should already be on Debian but worth a check) and then also check the device time to make sure it is not off at all
Yes, time was checked. The bare metal hypervisor, the VM and the client are synchronized from the same time keeper. Thus, we can rule out time being the issue.
–
However it does beg the question of time accuracy - eg: how much offset is acceptable and on what scale? seconds, ms, us, ns?
One other point, your post speaks to “during stage1” whereas I’m getting “Could not verify the server key. x-gpgauth-authenticated should be set to false during the verify stage”. Those seem to be different and not sure of the implications.
@doubts since you are getting an error message that is different than the one for this topic you will likely want to create a new one to avoid confusion. The error message you are mentioning now looks to be the same one mentioned on a different topic which for that one it looks like the key was made with a passphrase. So, when setting this up did you have the web installer generate a key for the server or did you provide one?
Some constructive feedback, as I finally got it working:
- There are points in the install script that need to be clear. For example, when the server’s FQDN is required - it should be called out as “FQDN” not “domain name” as that infers the DNS suffix.
- The real issue/error seems to have stemmed from the part of the install that uses a browser and occurs just before the underlying GPG crypto is performed. It references “server” and the sample text is mis-leading as it looks more like a comment than [again] an FQDN. It’s where you specify the server and the server’s email. (same page where you have the option to import the GPG key data). If you specify a single word such as “passbolt” instead of “passbolt.company.com” - apparently you get that GPG error. However, performing a fresh install and specifying “passbolt.company.com” AND provided that’s how users will refer to it in the browser - works like a charm. The greyed initial text helps to mis-lead the user. Instead of the existing greyed text - perhaps greyed text as <my_server_name>.<my_dns_suffix> as user’s will refer to it in the browser.
- There are assumptions during the install that will cause frustration for those not familiar with passbolt or not familiar with the paradigm upon which passbolt works.
Believe these to be minor “tweaks” to what is otherwise a simple and robust installation script/setup. A couple simple changes and perhaps a little more descriptive text to help the person installing to understand how these values apply (downstream) would be very helpful.
One question this does raise is: If an administrator had to “rename” the server, it’s FQDN and the FQDN used in the URI - what would need to be done? Is this even possible? Or would it be a case of having every user export their passwords and then re-import after the new server is created? As certain artifacts appear to be inextricably linked. Now, could one argue that an insufficient amount of documentation was consumed - perhaps. However, if you step back and look at it through the focal point of getting something up quickly for POC… Your install script is about 98% FLAWLESS in terms of guiding the user and getting everything done “quick & easy”. It’s just a matter of more clarity (terms and/or description) during the complete install to make sure that the user is entering the correct information in all the right points. (Literally was doing a “blank slate” install letting the install do all the work and creating from scratch).
Thanks!