[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 troubleshoot the problem
[x] I describe the steps on how to reproduce the issue
I’m in the middle of moving our Passbolt server from a dedicated box to a VM on another server. We’ve been running it on the dedicated box for about a year and love it. The packages are about as 1:1 as we could get.
CentOS 7.7, PHP 7.2.24, MariaDB 10.3.20, NGINX 1.16.1
I copied everything from /var/www/passbolt on server 1 to server 2 with rsync over ssh.
When I first ran healthcheck it was reporting that I hadn’t imported the key and a few permissions issues, which I fixed by running their recommended commands. However, now I’m only down to issues with not having an SSL certificate on the site yet and it still says “Could not verify server key. The OpenPGP server key defined in the config could not be found in the GnuPG keyring.”. On the right, in the login area it says “Oops! Something went wrong” but there’s nothing new in the error logs.
Saw another similar issue where he mentioned time problems which apparently I had forgotten about, but after adjusting the server to the same timezone as the other the problem persists.
In my config file I have:
'passbolt' => [ // GPG Configuration. // The keyring must to be owned and accessible by the webserver user. // Example: www-data user on Debian 'gpg' => [ // Main server key. 'serverKey' => [ // Server private key fingerprint. 'fingerprint' => '35E9DFA05FCD47B7F4F78EE4576A68950CDDEFED', 'public' => CONFIG . DS . 'gpg' . DS . 'serverkey.asc', 'private' => CONFIG . DS . 'gpg' . DS . 'serverkey_private.asc', ], ],
and when I run
su -s /bin/bash -c "gpg --fingerprint" nginx I get:
/var/cache/nginx/.gnupg/pubring.gpg ----------------------------------- pub 2048R/0CDDEFED 2018-11-28 Key fingerprint = 35E9 DFA0 5FCD 47B7 F4F7 8EE4 576A 6895 0CDD EFED uid 360bolt <email@example.com> sub 2048R/A35C10CF 2018-11-28
So seems like the same key as my old server, and indeed, the healthcheck seems to think so as well.
The output of
sudo -u nginx ./bin/cake passbolt healthcheck also doesn’t contain any errors related to the key.
Random Thought I will check next: Database Encodings match.