To add some information I missed previously:
CentOS Linux release 7.5.1804 (Core) nginx version: nginx/1.12.2 mysql Ver 15.1 Distrib 5.5.56-MariaDB, for Linux (x86_64) using readline 5.1 PHP 7.0.29 (cli) (built: Mar 30 2018 08:06:59) ( NTS ) Passbolt: v2.0.7 1c07f215b57a7a47dc8addb177b031782b62b8f7
I checked the gpgauth/database encoding issue. [v2.0.0] That version of GPGAuth is not supported
SELECT table_schema, table_name, column_name, character_set_name, collation_name
FROM information_schema.columns
WHERE collation_name = 'utf8mb4_general_ci';
# Empty set (0.02 sec)
I believe my https certificates are setup correctly and signed by a 3rd party. curl is happy:
cameron@myserver /var/www/passbolt $ curl -v https://passbolt.domain.com
* About to connect() to passbolt.domain.com port 443 (#0)
* Trying 2607:5300:201:3100::3c13...
* Connected to passbolt.domain.com (2607:5300:201:3100::3c13) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=passbolt.domain.com
* start date: May 10 07:26:50 2018 GMT
* expire date: Aug 08 07:26:50 2018 GMT
* common name: passbolt.domain.com
* issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: passbolt.domain.com
> Accept: */*
>
< HTTP/1.1 302 Found
< Server: nginx/1.12.2
< Date: Sat, 12 May 2018 22:41:49 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Keep-Alive: timeout=5
< X-Powered-By: PHP/7.0.29
< Set-Cookie: CAKEPHP=mjek06q0cia1c7f8u1m0mb5mu4; path=/; secure; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< strict-transport-security: max-age=31536000; includeSubDomains
< Location: https://passbolt.domain.com/auth/login
< x-permitted-cross-domain-policies: all
< referrer-policy: same-origin
< x-frame-options: sameorigin
< x-xss-protection: 1; mode=block
< x-download-options: noopen
< x-content-type-options: nosniff
< X-GPGAuth-Version: 1.3.0
< X-GPGAuth-Login-URL: /auth/login
< X-GPGAuth-Logout-URL: /auth/logout
< X-GPGAuth-Verify-URL: /auth/verify
< X-GPGAuth-Pubkey-URL: /auth/verify.json
< Access-Control-Expose-Headers: X-GPGAuth-Verify-Response, X-GPGAuth-Progress, X-GPGAuth-User-Auth-Token, X-GPGAuth-Authenticated, X-GPGAuth-Refer, X-GPGAuth-Debug, X-GPGAuth-Error, X-GPGAuth-Pubkey, X-GPGAuth-Logout-Url, X-GPGAuth-Version,X-GPG-Body-Signature
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31536000; includeSubdomains;
<
* Connection #0 to host passbolt.domain.com left intact
I’m confused why healthcheck is reporting that I’m using self signed keys. I’m betting it’s something in how healthcheck tests the ssl as it gets the wrong hostname, according to this:
[FAIL] Hostname does not match when validating certificates.
I’m betting my server GPGkey issues has something to do with how I moved keys from root. I’m however unsure how this would the the case. When I installed v1 (1.6.9), I’m pretty sure I created the keys as root. I remember running these commands and exporting the keys to a passbolt config location:
gpg --armor --export-secret-keys root@myserver.domain.com > /var/www/passbolt/config/gpg/serverkey_private.asc
gpg --armor --export root@myserver.domain.com > /var/www/passbolt/config/gpg/serverkey.asc
I also noticed two different fingerprints in my v1 configuration files:
cameron@myserver /var/www/passbolt $ grep "'fingerprint'" ../passbolt.v1/app/Config/*
../passbolt.v1/app/Config/app.php: 'fingerprint' => '0DEF6E8D3011558C242476A5A37EAF8B3C29B2BC',
../passbolt.v1/app/Config/app.php.default: 'fingerprint' => '2FC8945833C51946E937F9FED47B0811573EE67E',
../passbolt.v1/app/Config/default.php: 'fingerprint' => '2FC8945833C51946E937F9FED47B0811573EE67E',
Looks like the 2FC... is some random fingerprint that comes with the source and 0DEF... is the fingerprint of the key I generated for root:
cameron@myserver /var/www/passbolt $ sudo gpg --list-keys --fingerprint
/root/.gnupg/pubring.gpg
------------------------
pub 2048R/3C29B2BC 2018-02-10
Key fingerprint = 0DEF 6E8D 3011 558C 2424 76A5 A37E AF8B 3C29 B2BC
uid MyOrg - myserver <root@myserver.domain.com>
sub 2048R/472E030E 2018-02-10
And so I copied /root/.gnupg to /var/www/passbolt/ (which is $HOME for passbolt-src user). As I described above, this fixed the healthcheck [FAIL]s. As far as I can tell, the following is exactly what is expected:
cameron@myserver /var/www/passbolt $ sudo -u passbolt-src gpg --list-keys --fingerprint
/var/www/passbolt/.gnupg/pubring.gpg
------------------------------------
pub 2048R/3C29B2BC 2018-02-10
Key fingerprint = 0DEF 6E8D 3011 558C 2424 76A5 A37E AF8B 3C29 B2BC
uid MyOrg - myserver <root@myserver.domain.com>
sub 2048R/472E030E 2018-02-10
I also copied the keys from the old v1 config and believe I have set the configuration to load those files specifically:
cameron@myserver /var/www/passbolt $ grep "'fingerprint'" -A 2 config/passbolt.php
'fingerprint' => '0DEF6E8D3011558C242476A5A37EAF8B3C29B2BC',
'public' => CONFIG . 'gpg' . DS . 'serverkey.asc',
'private' => CONFIG . 'gpg' . DS . 'serverkey_private.asc',
cameron@myserver /var/www/passbolt $ ls -l config/gpg
total 20
-rw-r--r-- 1 passbolt-src nginx 0 May 10 22:52 empty
-rw-r--r-- 1 passbolt-src nginx 1739 May 10 22:52 serverkey.asc
-rw-r--r-- 1 passbolt-src nginx 3505 May 10 22:52 serverkey_private.asc
-rw-r--r-- 1 passbolt-src nginx 3147 May 10 22:52 unsecure.key
-rw-r--r-- 1 passbolt-src nginx 6647 May 10 22:52 unsecure_private.key
Maybe GPG is refusing to use keys that have read permissions for all users?
I just realized that while the passbolt-src user has a keychain with the right key, nginx is the actual user running the PHP. Maybe it needs its own copy of the keys?
To summarize and clarify, I believe I am currently seeing 3 issues that might be related:
[FAIL]on/healthcheck/statuscheck. Likely because passbolt api is refusing to run because of GPGkey issues.[FAIL]onhttpsfor issues that I know are not true.- No indication of GPGkey failure on
healthcheckwhen website reports:Could not verify server key. The OpenPGP server key defined in the config could not be found in the GnuPG keyring.