Reverse proxy handling

[j-autuick]

My domain is: little-beak.com and little-beak.net

I ran this command: so far, nothing special, been using LE for years on little-beak.com.

It produced this output: N/A

My web server is (include version): Apache 2.4

The operating system my web server runs on is (include version): Debian 10

My hosting provider, if applicable, is:

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): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): whateve the latest version is, i updated my system no longer than a week ago.

I have a host running LE (little-beak.com) for years now, all is good.
However, I want to setup another server (little-beak.net), and run web applications from it. I don't want't to open up this machine to the world, but rather have it server through a reverse proxy I plan to setup on little-beak.com

Here is my question:
I know I could add little-beak.net to my current little-beak.com certificate (I think I may have already done that). I also know, if the second machine had full access to the internet, I could just setup LE there. My router forwards all http traffic to little-beak.com (it's a basic router).

I had setup a basic reverse proxy on the above simple example, and it worked as expected. Now, I want to take the next step, and secure the second server with LE.

So, after all that, my actual question:
How does the certificate get passed? For example, so I just type https://little-beak.net it gets sent to little-beak.com server, which then proxy's it to http://little-beak.net? So when accessed from the "outside" it will be secure -- but between my local machines, it will be "normal http?"

If that is the case, that would be acceptable.

What if the web application NEEDS to use https - I guess I could make a self-assigned one - in between the two location machines? Hmm thinking out loud. This second case is for bitwarden, which I have been wanting to install--but is also containerized raising the complexity a level.

Anyway, any help would be greatly appreciated.

[rg305]

@j-autuick

So when accessed from the "outside" it will be secure -- but between my local machines, it will be "normal http?"

In a normal reverse proxy setup, yes, the proxy terminates the TLS connenction.
After that, and between your servers is up to you.
If your app, in the inside server, must be encrypted and the cert must be from a global CA...
Then you must somehow either pass/copy the cert in use by the proxy to the inside server or reduce the proxy to a mere stream (so that it doesn't terminate the TLS connection).
You could also temporarily proxy the HTTP challenge requests to the inside server - allowing it to get it's own cert via HTTP authentication.
And there is also always DNS authentication - which can be done manually from any IP that has access to the Internet. [that method could be even used on both servers at the same time]

In brief, there are many ways to get this done.
Most of which are very manual.
The ideal solution would be completely automated and that seems to involve some scripting to pass the cert or DNS authentication via API.

[j-autuick]

Thank you for the reply, it was very informative.

I ran into the problems you mentioned, with Bitwarden, since it WANTED the certification location (which naturally was on the other host). It had an extra layer of complicity since it was containerized, so I tabled the whole thing for now.

But, trying to get another web app running, which doesn't have the stringent requirement of a certificate. I will look into the DNS authentication option, as that looks most intriguing. Hopefully it's not too complicated.

[_az]

I don't know if Bitwarden will be happy with this, but you could just give Bitwarden a self-signed certificate.

That way, the reverse proxy leg of the connection (Apache→Bitwarden) would be secured using the self-signed certificate.

Meanwhile, the user-facing leg of the connection (Internet→Apache) would still be secured using the trusted Let's Encrypt certificate.

From Bitwarden's perspective, the provenance of the certificate it uses should make no difference.