Using Let's Encrypt behind reverse proxy also using Let's Encrypt

[SocialismTools]

My domain is: socialism.tools

My web server is (include version): NGINX 1.18.0 on reverse proxy

The operating system my web server runs on is (include version): Ubuntu 20.04

My hosting provider, if applicable, is: Home

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): N/A

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.40.0

Problem: I've installed Cloudron at home, a program that lets you easily install lots of other programs. It uses LE to provide certs to those programs. One program it doesn't support is Zulip, so I spun up another VM at home to install Zulip on manually, and added a redirect on the Cloudron server's NGINX like this:

server {
    server_name zulip.socialism.tools;
    listen 443;
    location / {
        proxy_pass https://zulip.socialism.tools;
    }
  }

But I get a 500 Internal server error when trying to see the Zulip setup page (Zulip's certbot seems to have ran fine). Any ideas on what's causing this? I also see “certificate not valid” and the cert seems to be the Cloudron cert, not the Zulip cert.

[Nummer378]

Hello @SocialismTools and welcome to the LE community.

@SocialismTools

added a redirect on the Cloudron server's NGINX like this

The nginx config block shown appears to attempt reverse proxying. This means that the nginx server (from Cloudron) terminates the (HTTPS) connection and forwards requests and responses between your "backend" (Zulip) and the client (browser). It's not clear to me if you want an actual HTTP redirect, or want to do reverse proxying - those are different things.

In case you want to do reverse proxying, your nginx server block is missing a few things.

First of all listen 443 should read listen 443 ssl, otherwise nginx talks plaintext HTTP on that port. Second, you need to tell nginx which certificates to use for that server block. This usually boils down to adding these two directives to the block:

ssl_certificate /path/to/fullchain.pem
ssl_certificate_key /path/to/key.pem;

Note that this means that the certificates must be available on the Cloudron instance. The Zulip instance actually doesn't need a certificate at all and you can also proxy-pass via http (assuming that both apps are running on the same machine, or the network is secured via other means).

@SocialismTools

proxy_pass https://zulip.socialism.tools;

This can't work in any case, as it's referencing itself. The nginx block is already handling requests for zulip.socialism.tools port 443, and you're proxying to the exact same destination. You also probably don't need https for this, as the Cloudron frontend already talks HTTPS.

There are also a few other useful directives for reverse proxying, such as the HTTP version and a few other things, but you should focus on getting things running first.

If all you want is a HTTP(S) redirect from somewhere to somewhere, you don't need a reverse proxy at all. Just a redirect directive somewhere.

[SocialismTools]

Thanks for responding!

I was looking into the redirect directive as I don't need Cloudron terminating the SSL, I basically just want it not to interfere with what Zulip is doing at all but becuase they're all on the same network behind the same external IP I thought it had to reverse proxied somehow. I thought I could "blind" passthrough requests from the internet though cloudron to Zulip, which would let Zulip handle it's own SSL certs but still let it work with the reverse proxy.

I tried tweaking this after realizing this but never got it to work. I found instructions from zulip with a template on an nginx config for reverse proxy and ended up using certbot for zulip on the cloudron server.

[Nummer378]

@SocialismTools

I thought I could "blind" passthrough requests from the internet though cloudron to Zulip, which would let Zulip handle it's own SSL certs but still let it work with the reverse proxy.

Actually I just recalled that this is possible with nginx, at least with additional modules.

https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

This probably would have done what you wanted (it reads the SNI from the ClientHello and then passes through the TLS stream without decrypting). But it looks like you've solved this already.