# V2 Update issues. Server Key not loading. Healthcheck says keys are fine, but other things broken

**URL:** <https://community.passbolt.com/t/v2-update-issues-server-key-not-loading-healthcheck-says-keys-are-fine-but-other-things-broken/662>\
**Category:** Installation Issues\
**Created:** [May 11, 2018, 8:28pm UTC](https://community.passbolt.com/t/v2-update-issues-server-key-not-loading-healthcheck-says-keys-are-fine-but-other-things-broken/662 "2018-05-11T20:28:07Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![cinderblock](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.passbolt.com/cinderblock/32/201_2.png) [@cinderblock](https://community.passbolt.com/u/cinderblock)\
**Post date:** [May 12, 2018, 11:30pm UTC](https://community.passbolt.com/t/v2-update-issues-server-key-not-loading-healthcheck-says-keys-are-fine-but-other-things-broken/662/2 "2018-05-12T23:30:05Z")

</div>

To add some information I missed previously:

> ```plaintext
> 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](https://community.passbolt.com/t/v2-0-0-that-version-of-gpgauth-is-not-supported/314)

```mysql
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:

```plaintext
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:

```bash
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:

```plaintext
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:

```plaintext
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:

```plaintext
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:

```plaintext
cameron@myserver /var/www/passbolt $ grep "'fingerprint'" -A 2 config/passbolt.php

```

```php
                'fingerprint' => '0DEF6E8D3011558C242476A5A37EAF8B3C29B2BC',
                'public' => CONFIG . 'gpg' . DS . 'serverkey.asc',
                'private' => CONFIG . 'gpg' . DS . 'serverkey_private.asc',

```

```plaintext
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 `r`ead 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/status` check. Likely because passbolt api is refusing to run because of GPGkey issues.
- `[FAIL]` on `https` for issues that I know are not true.
- No indication of GPGkey failure on `healthcheck` when website reports:

> Could not verify server key. The OpenPGP server key defined in the config could not be found in the GnuPG keyring.

---

_[View the full topic](https://community.passbolt.com/t/v2-update-issues-server-key-not-loading-healthcheck-says-keys-are-fine-but-other-things-broken/662)._