Update from 3.4 to 3.5 : The jwt key pair cannot be created

Hello, upgrading from 3.4 to 3.5, I am facing the following issue :frowning:

JWT Authentication

[PASS] The JWT Authentication plugin is enabled
[PASS] The /etc/passbolt/jwt/ directory is not writable.
[FAIL] A valid JWT key pair is missing
[HELP] Run the create JWT keys script to create a valid JWT secret and public key pair:
[HELP] sudo su -s /bin/bash -c “/usr/share/php/passbolt/bin/cake passbolt create_jwt_keys” www-data

[FAIL] 1 error(s) found. Hang in there!

$ sudo su -s /bin/bash -c “/usr/share/php/passbolt/bin/cake passbolt create_jwt_keys” www-data

The JWT private key could not be created.

Can you provide guidance to let me create this JWT key ?

Cheers

Hi @farfade! Check permissions on jwt folder because the Fail message is saying it’s not writable (so can’t create them). Reference: Cannot get passwords on the Android App - #11 by max

Thank you @garrett for your interest ! Unfortunately, it does not work after having checked and try various permissions (see my log below)

Actually I am confused because the healthcheck about /etc/passbolt/jwt says “PASS” (checking the directory is NOT writable (for security purposes I think).

> # sudo chown -R www-data:www-data /etc/passbolt/jwt
> # sudo chmod 755 /etc/passbolt/jwt
> # sudo chmod 600 /etc/passbolt/jwt/jwt.key
> # sudo chmod 644 /etc/passbolt/jwt/jwt.pem
> # sudo su -s /bin/bash -c "/usr/share/php/passbolt/bin/cake passbolt create_jwt_keys" www-data
> 
> Public key path: /etc/passbolt/jwt/jwt.pem
> Secret key path: /etc/passbolt/jwt/jwt.key
> A JWT key pair was found.
> Use the force option to overwrite with a fresh new pair.
> This will log out all users currently logged in with JWT Authentication.
> 
> # sudo su -s /bin/bash -c "/usr/share/php/passbolt/bin/cake passbolt create_jwt_keys --force" www-data
> 
> The JWT private key could not be created.

Notice : I’ve got those other failures in healtchecks since the beginning of passbolt (at least the v2) but it never prevented the whole system working correctly, with many clients and users, so I don’t think the jwt generation error is related (probably the healtcheck does not trust my private CA and/or my wildcard cert)

[FAIL] Could not reach the /healthcheck/status with the url specified in App.fullBaseUrl**
[FAIL] SSL peer certificate does not validate
[FAIL] Hostname does not match when validating certificates

Another notice : creation (touch) of empty jwt.key and jwt.pem do not solve the problem (create_jwt_key --force still fails) AND breaks the system (the client says : internal error has occured).

Isn’t there a way to enable detailed error log for cake create_jwt_keys ?

Hi @farfade

We have written a documentation about creating manually JWT keys : Passbolt Help | How to generate JWT key pair manually

Maybe could you delete /etc/passbolt/jwt folder and re-start from the beginning ?

Some additional tips:

You can check if your JWT key is OK with this command:

openssl rsa -in /etc/passbolt/jwt/jwt.key -check -noout

Must returns:

RSA key ok

You can next verify if the generated jwt.pem matches with the jwt.key file with this one-liner:

if openssl rsa -in /etc/passbolt/jwt/jwt.key -outform PEM -pubout 2>/dev/null | diff /etc/passbolt/jwt/jwt.pem - > /dev/null; then echo "OK: JWT key matches with JWT pem"; else echo "NOT OK: JWT key and pem doesn't match"; fi

If OK, going to https://your-passbolt-url/auth/jwt/rsa.json must display a json like the one below:

{"header":{"id":"c1e96a3e-40ef-4c8d-b2a7-18c0cbf3ade1","status":"success","servertime":1642846590,"action":"2a80ca92-0e47-5780-b338-3568f3cff69e","message":"L\u0027op\u00e9ration a \u00e9t\u00e9 effectu\u00e9e avec succ\u00e8s.","url":"\/auth\/jwt\/rsa.json","code":200},"body":{"keydata":"-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAyWFI+aGg4qpK6rJw6s1Z\n9KwnilZvXaIl+Fd7xIV1ycssc7IZrVqeYwcuzGamB1tQ8i5R5Hqc9161JPSvC6PD\n0nrXQhyLz2\/PxD6jbs8Ulg5hsSv968c1CAW0of6RIb9Lbq3Ur4f8K1qvwrfB6NN8\nTNOAs8FbVVq8W1\/9hSUtDe7r8QJk+BUj\/1CXKFcarcolFAXypGvqWEr1LQRiqzuN\nVDstopONGZXcDE1WNWvwkds3pCOhYOo0W7Z9ufkkaXJ53dVSTfxrNRw+NYAIc6NT\n2wcBiPWRdFp3vZvTpNHqKZg17RyPgwzALpPQOMN5W2auoaEs5dHEVEwVo0kciBKM\niSRewPo1egu3+TfvuuINq8gU3v6LhsXHlVqsnNVFgivotePy\/oCg3mPIaQTf9xVe\nTW3u+XW\/c2A\/KSxf5Lpc0cT\/hUPfABPnxQBLCMyTGGihC0eOc1TldoOMMPEv214J\n7u7KcPIoJ6O+34K1r4VHjQscCtRfeND7qznFqckl1hJhyXV3iYz3ys3NnNCGZDz5\nTvf6B1hVovzQO8lqt7JLX0j0+HDe3CncTVjpLSkoTGv8e2gDKOs\/aSFRBwOlU\/QZ\nBrKrQPIXwpryMoM\/HdTqtUY0So4Edq9uiatU8Kvf3VaY6oMvQGrLI6WG9g7g71ZI\nOvZx3R1edAtYSu1Wy5nXScsCAwEAAQ==\n-----END PUBLIC KEY-----\n"}}

Thanks @jc but it get stuck at the second step of the doc so I cannot go further :frowning:

sudo /usr/share/php/passbolt/bin/cake passbolt create_jwt_keys
The JWT private key could not be created.

and the folder remains empty :

 ls -la /etc/passbolt/jwt/
total 8
drwxr-x--- 2 root www-data 4096 Jan 22 11:45 .
drwxr-x--- 7 root www-data 4096 Jan 22 11:45 ..

Wouldn’t it be possible that the create_jwt_keys primitive miss some kind of dependency that was forgotten in the 3.5 migration script ? I was safely waiting for the stable release and did not do anything during the beta…

It is very strange :confused: I read in other topics you are using package on Debian, right ? Which Debian name and version are you using (cat /etc/os-release) ?

Can you give me the output of the php -i | grep -i ssl command (I let my output on Debian 11):

$ php -i | grep -i ssl
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3
SSL => Yes
MULTI_SSL => No
SSL Version => OpenSSL/1.1.1k
core SSL => supported
extended SSL => supported
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.1.1k  25 Mar 2021
OpenSSL Header Version => OpenSSL 1.1.1k  25 Mar 2021
Openssl default config => /usr/lib/ssl/openssl.cnf
openssl.cafile => no value => no value
openssl.capath => no value => no value
Native OpenSSL support => enabled

Thanks,

1 Like

I should be up-to-date from the Debian point of view :

$ cat /etc/os-release
PRETTY_NAME=“Debian GNU/Linux 11 (bullseye)”
NAME=“Debian GNU/Linux”
VERSION_ID=“11”
VERSION=“11 (bullseye)”
VERSION_CODENAME=bullseye
ID=debian
HOME_URL=“https://www.debian.org/
SUPPORT_URL=“Debian -- Support
BUG_REPORT_URL=“https://bugs.debian.org/

Here is the ssl stuff :

# php -i | grep -i ssl
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3
SSL => Yes
MULTI_SSL => No
SSL Version => OpenSSL/1.1.1k
core SSL => supported
extended SSL => supported
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.1.1k  25 Mar 2021
OpenSSL Header Version => OpenSSL 1.1.1k  25 Mar 2021
Openssl default config => /usr/lib/ssl/openssl.cnf
openssl.cafile => no value => no value
openssl.capath => no value => no value
SSL support => enabled
Native OpenSSL support => enabled

Thanks !

Got my eyes crossed on that one. Sorry for the confusion you are correct.

1 Like

@farfade Also, I know you’re digging in and are asking about debug logs… passbolt_api/JwtKeyPairService.php at beb4b528f2760f24cfc8221d22a4ccac76bcec9b · passbolt/passbolt_api · GitHub This is what @_jc is narrowed in on. The exception logs have high detail, which is very helpful.

1 Like

Thanks, this was exactly the pointer to the good code snippet I was looking for !

It told me the failing function was “openssl_pkey_new”. Googling around, I found that “You need to have a valid openssl.cnf installed for this function to operate correctly”.

On my - pretty standard I think - Debian system, I had no /etc/ssl/openssl.cnf file.

cp /etc/ssl/openssl.cnf.dpkg-dist /etc/ssl/openssl.cnf

solved the problem : create_jwt_keys now terminates correctly.

Thanks again @garrett and @_jc . Passbolt is a so beautiful software, and this community a pleasant place :slight_smile:

NB : by the way, creating /etc/ssl/openssl.cnf also solved the three other errors (see my previous post) the healthchecks have been reporting for two or three years

1 Like

Yes, I would like to see your ssl config because of the failing openssl_pkey_new function. I thought ssl was disabled somewhere in php.uni but it was elsewhere :stuck_out_tongue:

It is great we manage to find the solution all together :muscle:

It was a very interesting case, enjoy the mobile app :slightly_smiling_face:

1 Like

For clarity for any other Debian user : my brand new /etc/ssl/openssl.cnf config file is a quite long one (362 lines) beginning by the lines below.
There is absolutely nothing particular or customised by myself, just a copy of the one shipped by debian in /etc/ssl/openssl.cnf.dpkg-dist

> #
> # OpenSSL example configuration file.
> # This is mostly being used for generation of certificate requests.
> #
> 
> # Note that you can include other files from the main configuration
> # file using the .include directive.
> #.include filename
> 
> # This definition stops the following lines choking if HOME isn't
> # defined.
> HOME                    = .
> 
> # Extra OBJECT IDENTIFIER info:
> #oid_file               = $ENV::HOME/.oid
> oid_section             = new_oids
> 
> # System default
> openssl_conf = default_conf
> 
> # To use this configuration file with the "-extfile" option of the
> # "openssl x509" utility, name here the section containing the
> # X.509v3 extensions to use:
> # extensions            =
> # (Alternatively, use a configuration file that has only
> # X.509v3 extensions in its main [= default] section.)
> 
> [ new_oids ]
> 
> # We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
> # Add a simple OID like this:
> # testoid1=1.2.3.4
> # Or use config file substitution like this:
> # testoid2=${testoid1}.5.6
> 
> # Policies used by the TSA examples.
> tsa_policy1 = 1.2.3.4.1
> tsa_policy2 = 1.2.3.4.5.6
> tsa_policy3 = 1.2.3.4.5.7