Ugrading Debian broke Passbolt

Installation Issues
1

Checklist
I have read intro post: https://community.passbolt.com/t/about-the-installation-issues-category/12
I have read the tutorials, help and searched for similar issues
I provide relevant information about my server (component names and versions, etc.)
I provide a copy of my logs and healthcheck
I describe the steps I have taken to trouble shoot the problem
I describe the steps on how to reproduce the issue

A couple of days ago I decides to upgrade Debian 12 to Debian 13 for our organisation. The upgrade itself went fine and without issues. But Passbolt refused to work after this. I found this in the error logs:

2026-03-24 11:12:46 error: [Laminas\Diactoros\Exception\InvalidArgumentException] Unsupported scheme “https, https”; must be any empty string or in the set (http, https) in /usr/share/php/passbolt/vendor/laminas/laminas-diactoros/src/Uri.php on line 478
Request URL: /auth/verify.json?api-version=v2

This only appeared after the upgrade. I did some troubleshooting but couldn’t find the source of the error, so I needed to roll back the entire WV to previous state running Debian 12. Then everything worked again.

I did some digging in the code, and looked at line 478 which seems to do some checks for what protocol is used. I have Passbolt behind BunkerWeb WAF (and Keepalived in front of that), and BunkerWeb terminates SSL thru Let’s Encrypt. I have a long TSL-cert for the internal communication between BunkerWeb and Passbolt server itself to. Passbolt itself in bare Linux installation (no docker).

I tried commenting out the checks in the code, but ended up with redirect loop (ERR_TOO_MANY_REDIRECTS).

This setup is working good running Debian 12, but failed after the upgrade to Debian 13.

Any idea what’s happening here? I’m running Passbolt at home to, but within docker on Debian 13, without issues.

Debian 13 upgraded php version from 8.2 to 8.4. If that could have something to do with it? I have the database on another server running MariaDB. Passbolt serverversion is v5.10.0, CE edition.

2

Any ideas about this issue? I have to upgrade the system to newer Debian, especially since there is some kernel exploits released recently that don’t have a patch for older systems. I have mitigated it so far, but still need to update the system.

3

G’day zynexiz,

Reading the error message, my first guess is that this isn’t really a passbolt or PHP problem. Something in the proxy chain in front of passbolt is setting X-Forwarded-Proto twice; nginx then folds two same-named headers into one comma-joined value per RFC 9110 §5.3, and laminas-diactoros refuses to accept "https, https" as a URL scheme because {http, https} is the allowed set. That’s a hypothesis from one line of a log though, so worth confirming what the header actually looks like by the time it reaches passbolt’s own nginx before chasing it.

I don’t think PHP 8.2 to 8.4 is the cause. Your own data point (Docker on Debian 13, same PHP 8.4, working fine) is what makes me think the variable is the proxy chain on the bare-metal host, not the runtime. Best guess is BunkerWeb (or its bundled nginx) got upgraded alongside the OS and is now adding X-Forwarded-Proto at two stages in its pipeline rather than one, but that’s just a guess.

If you wanted to confirm, the way I’d start looking is to add a temporary log line on the passbolt host. In nginx.conf’s top-level http {} block:

log_format xfp '$remote_addr "$http_x_forwarded_proto" "$http_x_forwarded_for" $request';

and a second access_log line in the passbolt vhost so the existing one is undisturbed:

access_log /var/log/nginx/passbolt-xfp.log xfp;

Reload, hit the site once, tail -1 /var/log/nginx/passbolt-xfp.log. If the second field reads "https, https", that’s where to focus next. If it’s a single "https", something else is going on and worth coming back here with what you saw.

If that’s what it is, the cleaner fix is in BunkerWeb: set X-Forwarded-Proto once, at the proxy that terminates TLS, and not again downstream. A quicker workaround is to pin the value on the passbolt side with fastcgi_param HTTP_X_FORWARDED_PROTO "https"; inside the location ~ \.php$ block. That’s safe here because all traffic to passbolt is HTTPS anyway, but it masks the duplicate header rather than fixing it.

Worth flagging that commenting out the laminas scheme check isn’t a fix. The redirect loop you got is what happens when the URI keeps https, https as its scheme: passbolt’s redirect logic doesn’t recognise that as HTTPS, so the force-SSL path redirects to itself. You’d be trading a 500 for a loop without addressing the actual header.

Cheers,
Gareth