Passbolt Desktop App / Browser Extension Fails for All Users — “Could not verify the server key” and “Server response could not be parsed”

[emad]

Hi Passbolt team/community,

I’m creating a new post because my previous report did not receive a technical response, and the issue is still affecting all users in our environment.

We are running Passbolt Community Edition 5.14.3 on Ubuntu. The Passbolt server is behind a separate Nginx reverse proxy that terminates HTTPS. I have intentionally omitted the public hostname and internal IP addresses from this post.

Current issue

Both the Passbolt browser extension and desktop application are failing for all users and on multiple machines.

The browser extension reports:

Something went wrong!
Could not verify the server key.
Server internal error. Check with your administrator.

The desktop application shows:

Sorry, you have not been signed in.
Something went wrong, the sign in failed with the following error:
An internal error occurred. The server response could not be parsed. Please contact your administrator.

I have attached screenshots showing both errors, as well as the browser extension console/network activity.

Important finding: the request does not reach the Passbolt backend

While reproducing the issue, I monitored the Passbolt backend Nginx access log in real time.

When the desktop application or extension fails, the expected request to the Passbolt authentication/server-key endpoint does not appear in the backend access log at all.

This is particularly interesting because direct requests from the LAN/backend to the Passbolt endpoint work correctly and return HTTP 200 with valid JSON containing the expected server public key and fingerprint.

This suggests that the failure may be occurring before the request reaches the Passbolt application.

Browser extension console

The attached screenshot also shows repeated errors from the extension, including:

Error: The user id cannot be empty
Error: The user is not set
legacy account cannot be retrieved, please contact your administrator.
TypeError: Cannot read properties of undefined (reading 'toDto')

These errors also occur after completely removing and reinstalling the extension and clearing the browser’s cookies/site data.

The problem reproduces on multiple machines and browsers, so it does not appear to be specific to one user’s local extension storage.

TLS certificate chain

I also checked the HTTPS certificate presented by the reverse proxy with OpenSSL.

The connection reports:

Verify error:num=20:unable to get local issuer certificate
Verify error:num=21:unable to verify the first certificate
Verify return code: 21 (unable to verify the first certificate)

The reverse proxy appears to be serving the leaf certificate without the complete intermediate certificate chain.

Interestingly, using curl -k to ignore certificate validation allows the HTTPS request to succeed and return the expected Passbolt JSON response.

Because the Passbolt desktop application and extension fail before the request appears in the backend logs, I am wondering whether strict TLS certificate validation could be involved.

What I have already checked

• Passbolt upgraded from 5.14.0 to 5.14.3 successfully

• Database is healthy

• Passbolt migrations completed successfully

• GPG healthchecks pass

• GPG fingerprint and keyring are correct

• Local Nginx/PHP-FPM are working

• No local firewall rule is blocking the traffic

• Direct requests to the Passbolt endpoint return HTTP 200

• Extension was completely removed/reinstalled

• Browser storage/cookies were cleared

• Same issue occurs on multiple clients/users

• The problem affects both the browser extension and desktop application

There is also currently an NTP synchronization warning on the backend, although I have not yet established whether that is related.

Questions for the Passbolt team

1. Can an incomplete TLS certificate chain cause the desktop application or browser extension to fail with “Could not verify the server key” / “The server response could not be parsed” before the request reaches the Passbolt backend?

2. Does the Passbolt desktop application or browser extension perform stricter TLS certificate validation than normal browser navigation?

3. Are the extension errors such as “The user id cannot be empty” and “The user is not set” expected secondary errors when the initial server verification fails?

4. Is there a recommended way to enable more detailed debugging for the desktop application or extension to identify exactly where the verification/handshake is failing?

5. Could NTP/clock synchronization problems cause this type of server verification failure, or is that unrelated?

At this point, the two strongest clues are:

1. The failing request does not appear to reach the Passbolt backend.
2. The HTTPS endpoint currently fails full certificate-chain validation.

I have attached three screenshots showing the extension console, browser/network activity, and desktop application error.

Any guidance from the Passbolt team would be greatly appreciated.

[antony]

Hello @emad,
Sorry for the wait, and sorry your first post went unanswered. We help where we can on the forum but we do not always get to everything, and threads occasionally slip through, so thank you for coming back rather than giving up on it. One small suggestion for next time, replying in the original thread to bump it usually works better than opening a new one, it keeps the history in one place and it avoids leaving the first thread unanswered in the abyss at the bottom of the pile.

IMHO, you should stop reinstalling the extension, and tell your users the same. The account and the OpenPGP private key live in the extension’s own storage, not in the site cookies, so clearing cookies was harmless but removing the extension destroys the key material. Since I believe you are using the Community Edition, it means that it has no admin-assisted account recovery, so if you have any user without their recovery kit, you will need their account deleted and recreated, losing their unshared passwords. Anyone whose extension still works should download their recovery kit now. That is also where your console errors come from, “The user id cannot be empty” and the others are non-fatal and just mean no account is configured, so I would set that screenshot aside.

One thing worth knowing before anything else, “Could not verify the server key. Server internal error.” does not always mean passbolt returned a 500. The extension raises it for any failure during server key verification, including a request that never got a usable response at all. That could be why your backend log looks empty, I admit it’s a bit misleading.

So far, I think the desktop application error narrows it down. “The server response could not be parsed” is usually raised when a response did arrive and was not JSON. So on that client something answered and it was not passbolt, which fits a proxy error page or a WAF block, and would equally leave no line in your backend log. The usual suspects are a 502 or 504 page from the proxy, a WAF rule returning its own HTML block page, or a request that never gets routed upstream and lands on the proxy’s default vhost. Some WAFs and inspecting proxies also rewrite or inject into the response body, which breaks JSON parsing just as effectively.

Regarding what you’ve asked about NTP, I guess I’d start with the NTP warning, it is the cheapest item on your list and it is not a side issue here. GPG validates key timestamps against the system clock (on both the server and the client side), so a clock that is off can make the server key unusable and the verify token operation fail, and we have seen this exact error string come out of a clock correction before. What argues against it is that your GPG healthcheck passes, and that check encrypts and decrypts with the same clock, so it would be useful to know when you ran it relative to the warning appearing. Our NTP guide covers the setup. It is also a good discriminator, because if the clock is the cause you will get a real 500 and a line in your backend access log, which is exactly what you are not seeing today.

To answer your first question directly, yes, an incomplete chain can break a client before the request ever reaches passbolt. But I do not think that is what is happening here. Your own network screenshot shows the recover page loading over HTTPS with everything at 200, including requests made by the extension itself, so TLS is validating fine in that browser. And the desktop error is a parsing failure, not a handshake failure. Fix the chain anyway, it is a real defect and it will bite you elsewhere, but I would not expect it to change this symptom.

I think, the log we are missing today is the reverse proxy’s own access and error log at the moment of a failed sign-in. An absent line on the backend does not tell us whether the request died in transit or whether the proxy answered on its own.

Two small questions:

• Is there anything else in the path besides the NGINX reverse proxy, a WAF, ModSecurity, a cloud proxy?
• Is /auth/verify.json the only request failing on that machine, or does everything fail on the others?

Unrelated to the issue itself, one of your screenshots shows the URL bar, so the hostname you redacted elsewhere is visible. You may want to edit the post.

Best regards,