Installation behind nginx rev. proxy fails (2)

Installation Issues
1

Hi,
I want to re-open the issue already started at “Installation behind nginx rev. proxy fails” at
https://community.passbolt.com/t/installation-behind-nginx-rev-proxy-fails/2317/14

The issue that

https://passbolt.freifunk-stuttgart.de/var/www/passbolt/auth/login

is not available (404) is still open. healthcheck shows:

Environment

[PASS] PHP version 7.3.13-1+0~20191218.50+debian9~1.gbp23c2da.
[PASS] PCRE compiled with unicode support.
[PASS] The temporary directory and its content are writable.
[PASS] The public image directory and its content are writable.
[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
[PASS] The passbolt config file is present

Core config

[PASS] Debug mode is off.
[PASS] Cache is working.
[PASS] Unique value set for security.salt
[PASS] Full base url is set to http://passbolt.freifunk-stuttgart.de
[PASS] App.fullBaseUrl validation OK.
[FAIL] Could not reach the /healthcheck/status with the url specified in App.fullBaseUrl
[HELP] Check that the domain name is correct in config/passbolt.php
[HELP] Check the network settings

SSL Certificate

[FAIL] SSL peer certificate does not validate
[FAIL] Hostname does not match when validating certificates.
[WARN] Using a self-signed certificate

Database

[PASS] The application is able to connect to the database
[PASS] 23 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/www/.gnupg.
[PASS] The directory /var/www/.gnupg containing the keyring is writable by the webserver user.
[PASS] The server gpg key is not the default one
[PASS] The public key file is defined in config/passbolt.php and readable.
[PASS] The private key file is defined in config/passbolt.php and readable.
[PASS] The server key fingerprint matches the one defined in config/passbolt.php.
[PASS] The server public key defined in the config/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.

Application configuration

[PASS] Using latest passbolt version (2.12.0).
[PASS] Passbolt is configured to force SSL use.
[FAIL] App.fullBaseUrl is not set to HTTPS.
[HELP] Check App.fullBaseUrl url scheme in config/passbolt.php.
[PASS] Selenium API endpoints are disabled.
[PASS] Search engine robots are told not to index content.
[PASS] Registration is closed, only administrators can add users.
[PASS] Serving the compiled version of the javascript app
[PASS] All email notifications will be sent.

4 error(s) found. Hang in there!

if I use https for fullBaseUrl I get one error less, but still I have

[FAIL] Could not reach the /healthcheck/status with the url specified in App.fullBaseUrl

as the key issue. I see no issue with the certificate or the nginx proxy which receives the requests:

openssl s_client -connect passbolt.freifunk-stuttgart.de:443

locutus:~ # openssl s_client -connect passbolt.freifunk-stuttgart.de:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = passbolt.freifunk-stuttgart.de
verify return:1
---
Certificate chain
 0 s:CN = passbolt.freifunk-stuttgart.de
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGdDCCBVygAwIBAgISA/pdBEa6+0Q3yY6H5XpooCnAMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDAxMDQwOTAzNDhaFw0y
MDA0MDMwOTAzNDhaMCkxJzAlBgNVBAMTHnBhc3Nib2x0LmZyZWlmdW5rLXN0dXR0
Z2FydC5kZTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMlSshyz8zSI
5NI1XyhypBwoBpyH8oSdHmp5A7JQu5OzAykhQqasX6vXyhwof7uEoeKzRsgY4Xj5
ruE2n25qrRkCIDFAqSqg2yIpngt7HIjFDjO4tS9fbqTjI1RGOo1VzQiengcOdRZy
Z/KDsMv83b7X7/yEr6XVDpbkQWgLbm15Av3FMEa43e+jucVAJz48qJsQdYBeQcKn
5mlTCG5ggZv097HKTpUBpNBy8tzDXPpd/jELjfm54jqMrctE9x/n2l2vkn+6znG6
l6Yu0UUV2VahF5KjsRVmTh2KKIsTrOZ1R3WXQXTYgMudy8dBQw0XUD2FD8b93xRM
7fa7fsdqCUVY810EN9R+5sDjGoli4T6EFPKA75rYN9xWXJOD3Vg9/X0l8Bj2DOQ7
MCgu7lVnTDdkW089KkMqqTE8AzI28JmHXbJX2dIogSyyA1PZspjgfNS2LlhyJaYl
fBsOyC5SKlJfTcYuE7E+Z/T4H6XJf2SaLZKFTbXMRjxzylATyRWTq+qsNC83ttRB
sZfQYbOhl4Dvju3fndAsdQtJl8O9H6q3/MVAJLEVOueIYqdjME3kApwj6Fp0GW3s
/wheIiMbUP5RTEuAcqojQJXgie7DxrjPYSTLcwEwOPlGnfFKRFHOkFDgI8K/tvJm
PA6XVso94/wbQLvQj33+MBKABlFadDN1AgMBAAGjggJzMIICbzAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQC
MAAwHQYDVR0OBBYEFHGc9CXlsYMHNZpgMuU6WLjMoVmIMB8GA1UdIwQYMBaAFKhK
amMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMwYTAuBggrBgEFBQcwAYYi
aHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9yZzAvBggrBgEFBQcwAoYj
aHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9yZy8wKQYDVR0RBCIwIIIe
cGFzc2JvbHQuZnJlaWZ1bmstc3R1dHRnYXJ0LmRlMEwGA1UdIARFMEMwCAYGZ4EM
AQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0
c2VuY3J5cHQub3JnMIIBBAYKKwYBBAHWeQIEAgSB9QSB8gDwAHcAb1N2rDHwMRnY
mQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAFvcALIyAAABAMASDBGAiEAjkeyHd/D
NAuP/Ztpn+/jMKhKXcRG4XLCVw8GAp2fRfwCIQCoOa/wlCivAED70pNhkSmxj1dE
NNJBw1Yiz/U6qrPPEwB1AAe3XBvlfWj/8bDGHSMVx7rmV3xXlLdq7rxhOhpp06Ic
AAABb3ACyPMAAAQDAEYwRAIgElFBwQp7SaVqyU4yUF1YqKi4fdbrwe8nfYd0tWFg
G9wCID2HWUAVx8Ivah+YpswqL0UF0uKV1NmeMBgOn6dyMPnoMA0GCSqGSIb3DQEB
CwUAA4IBAQB4WbrA+lECWyhmZzwmGPJNmOsQz1R2S37l1Dl/4IWfvdwRjJvA+c29
jA5vmd0xvUttG6isSc2pZ4MNT9zEcZ935G7IL+5cNrjOAhb3ci8crM78K+rl2pbe
no4VMsIzWBJI6RDZaH+uYHY3iX7tDt4vI47UjUZHBFWA1uLSRg2aCGp2o72IZHqK
MGG/KXCdmwAc6b4DfzOaGifkgHjFg2L8izzzobBr8Ty27iD2oc8qSsoVXAEBhaPx
gVT2sJPGEQjUMruDCxXsFgGsnZOEQpDrx+ODm8dFhAqNFaw06fPAItSh0qzelj6f
MhyakbhHUqYlaG73yBLZLpaBFEppxIrB
-----END CERTIFICATE-----
subject=CN = passbolt.freifunk-stuttgart.de

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3766 bytes and written 425 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: F1A3499C9571DD3F4F5A3AE3384B3EDD769527AFE7D6D7C2FC61B1A3A401D32B
    Session-ID-ctx: 
    Master-Key: 6A1FC518F32C53326F8B1728158E70D40571CC285B7A0E6FE12AB0B5A2E779179850ED45BBEA3007D2BF5D90EE25CA71
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 86 eb 9d a4 42 73 c0 60-d7 0f 85 46 cc 2f 7a be   ....Bs.`...F./z.
    0010 - a2 84 11 02 e4 cf 06 05-c0 7b 4a 2a fc ce af 84   .........{J*....
    0020 - 62 38 bb dc 9c 82 41 02-c2 18 ad ee fa 42 4f 42   b8....A......BOB
    0030 - b9 42 1a 17 bc 89 d3 50-d4 ad f5 e6 db a9 e9 41   .B.....P.......A
    0040 - a5 00 cd b7 72 5c 26 1e-19 00 f2 97 3b e5 28 3d   ....r\&.....;.(=
    0050 - 24 88 a0 0b 21 aa 2a 06-3d 05 87 52 ea 4d 4c 53   $...!.*.=..R.MLS
    0060 - fc cd 60 8f bf 15 0a 20-54 20 20 8e 31 f1 91 31   ..`.... T  .1..1
    0070 - 71 42 4f db b1 d6 ba fb-4a 2e ac da 65 69 1e 70   qBO.....J...ei.p
    0080 - 1e f1 9a e1 c6 6b ca a3-d1 92 5b d4 05 df 5f b5   .....k....[..._.
    0090 - f7 f2 a1 29 62 a6 34 66-a7 70 da b1 b8 40 f2 b9   ...)b.4f.p...@..
    00a0 - 22 3b 20 4e 30 32 70 3b-34 d0 c0 d2 4d 53 74 48   "; N02p;4...MStH
    00b0 - da 44 84 bb 8d 80 7f cc-e5 1d 6b 9c 76 20 fb 80   .D........k.v ..
    00c0 - a1 17 c8 fa f1 b0 15 77-9a 22 3e ab fb fa 86 ae   .......w.">.....

    Start Time: 1579430393
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes

I have two passbolt installations running, one with haproxy, one wit nginx. The problems only appear at at the nginx setup.

2

Hi @Thommie,

Are you using Nginx and Apache on the same machine or two separate machines? If same, I think the problem is you are serving Passbolt on port 80, instead of like 8080 (closed to the internet on the firewall).

If Apache is on the same server as the Nginx reverse proxy, than the “upstream” for the Nginx reverse proxy is http://127.0.0.1:8080, in this example. No SSL cert needed for this, but settings in Passbolt should be changed to a different port, and run without SSL.

I may have misdirected you in all the back and forth…my Nginx reverse proxy is a separate server, and proxy_pass goes to a different IP and not a local port, which is what I am guessing you need in this case.

3

Hi Garret,
the whole setup is hosted on a proxmox virtualisation server and within lxc containers. The nginx is a separate container, the database (mariadb) another container and the webserver (apache) another one. Internal communication is done through an internal bridge.

This passbolt installation is the only one where I have problems. Other installations use haproxy instead of nginx. I am not familiar with nginx, but -up to now- it really looks as if the root cause is some error in the nginx config. Which would be good for me because then I could hand over the debugging to my colleague who is responsible for the reverse proxy :wink:

4

I use Proxmox as well, but all VMs, no containers.

You could try bypassing the Nginx reverse proxy and establishing a good Passbolt setup first.

What is doing the routing for your containers? Proxmox, or something else?

5

Th routing is done by proxmox, but it looks absolutely normal. Even my passbolt installation is practically identical to others which work fine. The only problem or difference which I can think of is the nginx stuff. So, whats your idea, do you also believe its a nginx issue? Then I could hand it over to my colleague and we could save some time … (at least your and my time ;- ) )

6

I’m not certain, really.

Here’s a checklist:

  • on reverse proxy container: when you try http://passbolt.freifunk-stuttgart.de see if connection is on port 80, and then changed to 443, and then an outgoing to your passbolt container ip address, port 80. I like to use tcptrack to see connection activity.
  • you should not see the passbolt container trying to connect on port 80
  • also try the site with https: and see it come in on 443 and then out to the passbolt server
  • on passbolt container: try the site again, make sure the connection is coming in on port 80 from reverse proxy
  • check the passbolt container logs (php logs, passbolt logs)
  • double check that the container and/or Proxmox firewalls are not blocking the connections
  • check system logs on Proxmox for the container, to see if there is any error

You are otherwise saying everything is not a problem…but a 404 is likely a passbolt container issue, in my opinion. If the reverse proxy could not get to the passbolt container, you’d be likely to get a Bad Gateway 502 response.

Good luck! I know you’ve put a lot of time into this.

7

I just checked the site, and the URL after attempt shows:

https://passbolt.freifunk-stuttgart.de/var/www/passbolt/auth/login

This means that the Apache web server on the passbolt container is pointing to root on the container, instead of /var/www/passbolt/webroot.

This is likely the problem.

8

Nope, I played with the ‘base’ => ‘/var/www’ directive in passbolt.php and you checked it just when it was active, it is now off again. I have the same config on both https://passbolt.freifunk-stuttgart.de and https://passbolt.netzwissen.de, but the latter works without any problems. The only difference: on @netzwissen.de I have no nginx in front, just the apache itself with a config for the subdomain.

9

Any luck with tracking down the connection path?

10

I am definitely running out of ideas:

  • re-installed php environment (7.3, there is a missing php-gnupg package when using 7.4)
  • re-installed apache 2.4
  • re-installed passbolt according to https://help.passbolt.com/hosting/install/ce/from-source.html
  • apache DocumentRoot is /var/www/passbolt as recommended. The identical setting is running without problems on other installations

When checking with curl on the localhost I receive a valid the inital page from the passbolt code:

* Rebuilt URL to: 10.0.3.235/
*   Trying 10.0.3.235...
* TCP_NODELAY set
* Connected to 10.0.3.235 (10.0.3.235) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.0.3.235
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Tue, 21 Jan 2020 18:14:35 GMT
< Server: Apache/2.4.25 (Debian) OpenSSL/1.0.2u
< Set-Cookie: CAKEPHP=nkfofr1c57a6u1pr3sacvud4bi; path=/; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self';frame-src 'self';
< strict-transport-security: max-age=31536000; includeSubDomains
< Location: https://passbolt.freifunk-stuttgart.de/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
< Set-Cookie: csrfToken=1b6da1eda59ed7b7843aedacfb7e7bda56f78a44ce332b98c3f8b8b4bb86e2fdf42627aee7e03c887277752e9d9a0aa357c66e30ef9565f84efed13d55d83b3e; path=/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
< 
* Curl_http_done: called premature == 0
* Connection #0 to host 10.0.3.235 left intact

But the redirect contained in the location header (the target of the 302) fails:

   Trying 10.0.3.235...
* TCP_NODELAY set
* Connected to 10.0.3.235 (10.0.3.235) port 80 (#0)
> GET /auth/login HTTP/1.1
> Host: 10.0.3.235
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Tue, 21 Jan 2020 18:27:55 GMT
< Server: Apache/2.4.25 (Debian) OpenSSL/1.0.2u
< Content-Length: 196
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>

My current point of view:
This is not a problem of any proxy (nginx etc.) and not a problem of the local webserver (apache). Instead its a problem of the passbolt code itself. I see no other reason why a request for the startpage should load normally but the redirected /auth/login URI should not. And the healthcheck does not give any insights where to look for …

11

Huh. You’re saying the Apache configs on both passbolt containers are identical, but you’re having a different result when you’re only working at a localhost level. That didn’t make sense except there must be something we’re not checking.

Try changing the hosts file so it does not have the x.235 reference, because localhost should be enough.

12

OK, you’re right, I did not check the /etc/hosts to get it in sync with my other installations. Now we have

root@passbolt:~# less /etc/hosts
127.0.0.1       localhost
127.0.1.1       passbolt
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
# --- BEGIN PVE ---
10.0.3.235 passbolt.freifunk-stuttgart.de passbolt
# --- END PVE ---
10.0.3.3 salt

which is the same as in other installations. Then restart the container, but still:

root@ffs03:~# curl -vv 10.0.3.235/auth/login
*   Trying 10.0.3.235...
* TCP_NODELAY set
* Connected to 10.0.3.235 (10.0.3.235) port 80 (#0)
> GET /auth/login HTTP/1.1
> Host: 10.0.3.235
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Tue, 21 Jan 2020 20:49:59 GMT
< Server: Apache/2.4.25 (Debian) OpenSSL/1.0.2u
< Content-Length: 196
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
* Curl_http_done: called premature == 0
* Connection #0 to host 10.0.3.235 left intact

Comparison on a healthy installation:

root@devel:~# curl -vv passbolt.netzwissen.de/auth/login
*   Trying 138.201.52.38...
* TCP_NODELAY set
* Connected to passbolt.netzwissen.de (138.201.52.38) port 80 (#0)
> GET /auth/login HTTP/1.1
> Host: passbolt.netzwissen.de
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 302 Found
< content-length: 0
< location: https://passbolt.netzwissen.de/auth/login
< cache-control: no-cache
< 
* Connection #0 to host passbolt.netzwissen.de left intact
13

… think we need someone who knows the code here …

14

Given all the changes you made, would you mind posting a current healthcheck again?

15

Also, this appears to be a message due to .htaccess settings.

16

Hi Garret, the issue is solved and the root cause was totally different: it was just a missing mod_rewrite module in the apache config. The .htaccess is unchanged but it contains

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteRule    ^$    webroot/    [L]
    RewriteRule    (.*) webroot/$1    [L]
</IfModule>

The problem: install instructions do not contain a requirement for mod_rewrite. Also the requirements.php code only checks for missing php modules but not for modules in the webserver, although this would be possible in php with apache_get_modules(). So, not a very good idea to provide only “nginx-centric installation instructions” while apache still dominates the worldwide webserver market (although nginx is close, I know) …

Anyway, it works now :wink:

17

Yes, good thoughts. And, now you are more experienced with both Apache and Nginx! Debate regarding dominance aside, they do work very well together.

18

Shure, but thats not my point. Its more a critic towards the passbolt documentation, which should be suitable for both products. I will open a ticket to get the docs updated …

1 Like
19

I use the passbolt dokcer image and have setup a nginx reverse proxy in front.
You can see the config details here: https://hub.docker.com/repository/docker/waarlandit/geopip-rproxy
Or use my reverse proxy docker image, what ever you like :slight_smile:

20

@R0N thanks for the offer, but the issue is already solved. My setup is a haproxy in front as reverse proxy and an apache as the backend server for the php environment. Te key issue was a missing mod_rewrite module which was not mentioned as a requirement in the online docs.