Install passbolt behind an existing Nginx Reverse Proxy

Hey Guys,

This may be a simple answer or based on the setup wizard may not be supported however her we go.

I have a large environment with quite a few services being offered by VM’s hosted in my environment. In order to provide remote access to these resources I have an NGINX reverse Proxy configured which handles all inbound web requests and proxies the request through internally to the relevant VM. At the moment I have about 35 or so different webservices working perfectly fine in this manner.

I would now also like to setup passbolt and have it operate the same way. Thing is though I can’t use SSL auto mode in the wizard as I’m not providing a route to VM directly and as such Letsencrypt will not be able to retrieve a cert. I’ve already setup my reverse proxy server block and I already have my Letsencrypt cert setup in my existing reverse proxy.

How do I go about enabling SSL prior to running the wizard so that I can configure it to work through my existing reverse Proxy??

Any and all help is greatly appreciated.

Checklist
[ ] I have read intro post: About the Installation Issues category
[ ] I have read the tutorials, help and searched for similar issues
[ ] I provide relevant information about my server (component names and versions, etc.)
[ ] I provide a copy of my logs and healthcheck
[ ] I describe the steps I have taken to trouble shoot the problem
[ ] I describe the steps on how to reproduce the issue

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.

The solution comes down to using other options regarding Let’s Encrypt certificates on a server behind a reverse proxy. As a starting point, I will assume that although the web server is accessible from the public only through the NGINX reverse proxy, it can itself access the internet on its own. For example, it can call out to get updates for the operating system, etc. and can connect directly to the internet. If this is not the case, there is a different solution needed, and one exists (see last section below).

I have a setup like yours and use the https://github.com/Neilpang/acme.sh script to automate certificate renewals with Let’s Encrypt. The script has a DNS API feature where one can implement an API Key through their domain name service provider (GoDaddy and their “developer” portal in my case). Instead of Let’s Encrypt connecting with your server, it connects with your domain provider and directs the API to establish a temporary key in your DNS settings which it then verifies.

Once the certificate is generated in this way, it must be installed to a location of your choosing. Assuming you create an “acmecerts” folder that the script can install the certs to, the script’s “cert installation” parameters can be established by using the following on the CLI:

acme.sh --install-cert -d passbolt.yourdomain.com \
--fullchain-file /etc/nginx/acmecerts/passbolt.yourdomain.com/fullchain.cer \
--key-file /etc/nginx/acmecerts/passbolt.yourdomain.com/passbolt.yourdomain.com.key

Using this script establishes settings so that future update certs will automatically get installed. The acme.sh script creates a folder with the name of yourdomain.com with a yourdomain.com.conf file in it that includes the parameters for the script. You will also need to change the “Le_ReloadCmd” parameter in that file to:

Le_ReloadCmd='service nginx restart'

…so that NGINX will restart after a future cert update and begin using the new cert.

Configure your behind-proxy server to use the certs at this location which will be used to connect securely to the reverse proxy server. With a certificate in place, the “manual” option can be used in the Passbolt setup.

But if you have no internet access or your domain provider has no API
There is also a manual process using the same acme.sh script but one must manually create a DNS entry with a provided hash which will act as a stand-in. The downside to this approach, of course, is no automatic updates which = automatic cert failure if you don’t remember to update before the 90-day expiration window.

1 Like

For future readers:

Le_ReloadCmd='service nginx restart'

is better if written as:

Le_ReloadCmd='service nginx reload'

because the reload command allows for NGINX to check for errors and abort if there is a problem. Restart will force an acceptance of configuration change - if there is a problem the service may stop and not restart.