Self registration does not work

[x ] I have read intro post: About the Installation Issues category
[ x] I have read the tutorials, help and searched for similar issues
[ x] I provide relevant information about my server (component names and versions, etc.)
[ x] I provide a copy of my logs and healthcheck
[ x] I describe the steps I have taken to trouble shoot the problem
[ x] I describe the steps on how to reproduce the issue

self-registration was working for us, but it suddenly stopped. The server responds with

“action”: “1c717cd7-d236-55c4-a068-b9a0923b1927”,
“message”: “This user does not exist or has been deleted. Please register and complete the setup first.”,
“url”: “/users/recover.json?api-version=v2”,
“code”: 404

The passbolt instance is running on 3.12.0-3-pro-non-root with redis enabled.

Healthcheck shell


[PASS] PHP version 7.4.33.
[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
[WARN] The passbolt config file is missing in /etc/passbolt/
[HELP] Copy /etc/passbolt/passbolt.default.php to /etc/passbolt/passbolt.php
[HELP] The passbolt config file is not required if passbolt is configured with environment variables

Core config

[FAIL] Debug mode is on.
[HELP] Set debug = false; in /etc/passbolt/passbolt.php
[PASS] Cache is working.
[PASS] Unique value set for security.salt
[PASS] Full base url is set to https://*****
[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


[PASS] The application is able to connect to the database
[PASS] 47 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 (3.12.0).
[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] The self registration provider is: Email domain safe list.
[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 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
[FAIL] The /etc/passbolt/jwt/ directory should not be writable.
[HELP] You can try:
[HELP] sudo chown -Rf root:www-data /etc/passbolt/jwt/
[HELP] sudo chmod 750 /etc/passbolt/jwt/
[HELP] sudo chmod 640 /etc/passbolt/jwt/jwt.key
[HELP] sudo chmod 640 /etc/passbolt/jwt/jwt.pem
[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.
[WARN] The SMTP Settings source is: env variables.
[HELP] It is recommended to set the SMTP Settings in the database through the administration section.
[WARN] The SMTP Settings plugin endpoints are enabled.
[HELP] It is recommended to disable the plugin endpoints.
[HELP] Or set to true in /etc/passbolt/passbolt.php.


The 404 error you got is expected. At this stage passbolt tries to identify the user and if it cannot depending this one will be redirected to the self registration journey if enabled.

Can you provide us with more information:

  1. Can you confirm that no request to the API follows the 404 one. We expect a request to the following entry point: /self-registration/dry-run.json.

  2. If yes to the previous point, can you provide with the response returned by the API.

  3. If no to the point 1. Can you request the following entry point: /settings.json and ensure it contains the plugin self_registration and that this one is enabled

        "passbolt": {
            "plugins": {
                "selfRegistration": {
                    "enabled": true
  1. Can you tell us if SSO is enabled or not?

  2. Can you provide with a screenshot of what you see?

  3. Can you provide with the output of the browser console?

Thank you for the tips. I did not know that the 404 is expected behaviour.

There is no request to the dry-run entry point.

I find the settings.json part really interesting because it contains everything as enabled, even though I disable it. Therefore SSO is listed as enabled in this response, even though it is disabled and not configured in the passbolt UI.

Screenshot of no following request

Single sign-on in UI

Everything is on even though it is not captured in an incognito window. Another option is that it is on somewhere, but the UI loads the wrong data.

1 Like

The settings.json endpoint informs that the plugin, aka feature is enabled, not that it has been configured and is active.

In the case of SSO, it states that an admin can enable SSO in the admin panel. If for example admins decide that they want to fully disable SSO, they can do so by setting an anvironement variable PASSBOLT_PLUGINS_SSO_ENABLED to false. This way SSO will disappear from the admin panel completly.

So SSO enabled means that it can be configured, but still admins need to configure it.

This applies to most feature plugins listed in settings.json.

Thank you for clarifying that. Well the self-registration is on, and I can indeed turn it on in the settings, but It does not work, and I do not see any issues in the container output.

Thank you for the additional information.

It seems that the journey is interrupted by an unexpected event. We currently have a known error relative to SSO but it’s not supposed to block this journey. Do you have any other errors in your browser console?

In Firefox, I get Content security policy blocked - („script-src“).

And in both firefox and Chrome I have
Error: The given SSO provider id is not valid
findSsoProviderId https://passbolt…/js/app/api-triage.js?v=3.12.0:2

Though I did not configure SSO and it should be disabled.

A fix for this error will be published within the next release, however it shouldn’t block this journey as we have the same one but cannot reproduce the issue here.

I don’t see anything, maybe someone from the team would see something else.

As very last resort, did you try to clean the cache of your browser!?

Thanks for your help.

I tried clearing the cache and different browsers. Other people reported the issue as well.

I managed to get into some weird state when in one browser on one account, I see the configuration as enabled, and then in another browser on another account, the configuration is off. One also incorrectly reports subscription status. I suspect that redis with sentinel might be causing this, but the logs seem ok to me, as I am not experienced with it. I tried force reloading in both browsers, but the situation is the same. Do you have any tips for troubleshooting redis?

EDIT: This happened after I promoted the other account to admin as well. However after logout and login, it seems to be working fine.

@cedric Hello; we managed to find out where the issue is.

We are running Passbolt in our Kubernetes, which has a custom 404 error page. As Passbolt seems to encode the instruction to start a new registration in this error message, it never got back to the client and therefore, the user could not self-register.

I want to propose a change to this behaviour and to return 200 instead of 404.

Why? Are you changing the shape of the passbolt application answers based on the status? We use HTTP codes in several places as part of the application logic, for example 404 the resource is not found, doesn’t mean that the page doesn’t exist but that the resource is not found.

1 Like

There is a whole debate on the correct response for non-existent entries. Unfortunately, the decision to send a 404 instead of an empty 200 was causing us technical issues. However, I can understand that if you use it the same way everywhere else, it would be troublesome to replace it. Maybe some mention of this could be in the documentation, as we had no other issues with our instance, and only the self-registration was not working, and it was pretty difficult to track the problem down.

Only if 404 is returning an object would it make sense to do a 200.

I’ve had to work with other APIs that use 404s to send back messages like {"message": "Item not found."}but then I have to parse exceptions which is a pain. Objects returned need to be handled in a 200.

But in an API when a request is made to a URI for a specific resource, it is standard practice to use 404 when it’s not found.

The difference in view may be Web page vs API response.

From HTTP response status codes - HTTP | MDN

404 Not Found

The server cannot find the requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 Forbidden to hide the existence of a resource from an unauthorized client. This response code is probably the most well known due to its frequent occurrence on the web.

Errors will be a 400 response.

I missed this. However, as a user, I do not expect an error here, which is the reason why I find the 404 confusing. The UI wants me to enter my email. The fact that Passbolt runs a query in the background to look up me in the database and uses an error as a way to find out that it should register me is sort of hidden from the user. Passbolt not finding me in the database does not necessarily mean that the action I started failed and, therefore, should error out. When I am trying to register, that is actually what is supposed to happen. However, as the registration process was broken for me and the flow itself is not in the documentation, I just assumed that I am querying some endpoint that just does not exist and, therefore, that my installation was broken. Therefore I did not consider checking out the API error responses.

I know this is an edge case and influenced by something out of your scope, but with the release of official Helmcharts, more people are likely to run Passbolt in Kubernetes and having some background info about this could help them save time troubleshooting. It was especially confusing, as our reverse proxy registered the 404 and replaced it with our custom 404 that contains { “message”: “404 The page you’re looking for could not be found.” } which is why I was thinking about 404 as a web error instead of an API one.

Thanks everyone for your help and responses, I am glad that you are actively participating in the discussion with the community :slight_smile:

Just to confirm: this issue wasn’t ultimately due to passbolt or the provided Helmchart installation instructions, correct?

What are you using as a reverse proxy? Maybe we can document an exception solution for this scenario - did you implement an exception or how are you handling this in your case? Are you still trying to resolve the issue?


Yes, Passbolt itself does not cause this, AFAIK. We are using Nginx, which was sending a custom 404 page, which broke the Passbolt self-registration flow. I managed to troubleshoot it with our K8s admin, and he could turn off the custom page for this scenario and keep it working for the situations we need it to be there.

He, however, said that this is a global setting, so if the custom 404 page stopped working in other scenarios, we could not use Passbolt with self-registration in our cluster. That is the reason I wanted to suggest using 200, as that is unlikely to be replaced by something along the way.

1 Like

Well, Passbolt also uses NGINX so it’s not a required NGINX setting to have the custom 404 page. NGINX can use a custom 404 globally but also have location exceptions.

Passbolt is based on an api, but doesn’t use a path /api so I would probably go with proxy_intercept_errors off in the reverse proxy location block.