Reverse proxy and letsencrypt certificate

Help
#1

Hi,

I have a question about creating a certificate.
I have 2 servers. One with nginx reverse proxy and one with the webserver itself apache.

Do I need to create the certificate for the domain on the reverse proxy server or on the backend webserver (apache)?

Because I am trying to set it up with dry-run and is succeeds on the webserver itself. But when trying to do this on the reverse proxy server it says unauthorized.

I already have a certificate on the reverse proxy for another domain and this is working as expected.

Thanks in advance!

2 Likes
#2

Welcome to the Let's Encrypt Community :slightly_smiling_face:

A certificate belongs to the domain name(s) being served and not to any particular piece of software. When acquiring a certificate using http-01 challenges, the ACME client (e.g. certbot) is responsible for creating a challenge file accessible via http://www.example.com/.well-known/acme-challenge/. Certbot handles the nginx and apache authenticators differently. For nginx, an exception is created in the webserver configuration to serve the directory. For apache, the file is created in the directory itself. Thus, you want to be sure to run the client such that the challenge file can actually be found via a GET request over port 80.

In terms of who serves the certificate, that would be the piece of software actually responding for port 443 (or whatever port you're using the certificate with). This is the software that terminates SSL/TLS (i.e. does the encrypting, decrypting, etc.).

1 Like
#3

Hello, you need them on both. I made similar post some minutes ago but it is about a renewal issue.
You can see there my configs as example.

#4

Not necessarily. You only need a certificate to be served by the entity responding for port 443 (or whatever port you're using the certificate for). Installing the certificate anywhere else will just leave it sitting there.

3 Likes
#5

Hey thank you for your help so far.
I got the certbot certificate request working on the backend server itself. But on the reverse proxy it won't pass.

What do I need to put in the nginx reverse proxy config to proxy to the backend and check the ssl in there?

2 Likes
#6

Something on your reverse proxy/nginx configuration is blocking this.

Based on "dry run", it sounds like you are running Certbot.

The easiest thing to do, IMHO:

  1. Run certbot in standalone mode
  2. Pass in the --http-01-port flag to run certbot on a port like 8080
  3. Have your nginx proxy pass all the traffic on /.well-known to port 8080 (or whatever you chose).

That should bypass most ways you may have created conflicts in your nginx setup.

That will allow you to terminate SSL on nginx, and then not worry about any ssl certificates on your apache backend servers.

2 Likes
#8

Everything below is from and executed on the reverse proxy. This is the command I execute on the reverse proxy webserver:

InkedScreenshot_1_LI
InkedScreenshot_1_LI1236×404 76.6 KB

Port 80 of the router is port forwarded to 81 on the reverse proxy.
And my http reverse proxy config:

   server {
       listen 81;
       server_name domain.domain.com; 

       location / {
       proxy_http_version 1.1;
       proxy_set_header Host $host;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_buffering off;
       client_max_body_size 1024M;
       proxy_pass http://192.168.2.151:81/;
       proxy_redirect off;
       }

       location /.well-known/carddav {
       return 301 $scheme://$host/remote.php/dav;
       }

       location /.well-known/caldav {
       return $scheme://$host/remote.php/dav;
       }
}

Do I miss something for the ./well-known?
The ./well-known stated already is needed as per installation instructions of nextcloud.

The webserver itself on the backend through the reverse proxy is working as expected. It went wrong from this part when creating the certificate from the reverse proxy server. When I do the webroot certificate creation on the backend server where the reverse proxy is sent too. It succeeds.

1 Like
#9

The well-known path used by Let's Encrypt for certificate issuance is /.well-known/acme-challenge, so I'd think you'll want to add a similar directive for that path.

2 Likes
#10

You mean to add this on the reverse proxy and send /.well-known/acme-challenge to the backend server?

1 Like
#11

Yes, that's right. :slight_smile:

1 Like
#12

I will try that right away, But then the question:
Why will the certificate request succeed on the backend server with the current reverse proxy configuration?
And fails when I execute the command on the reverse proxy?

Just executed it with the following added to the reverse proxy:
image

And tried this one afterwards:
image

But it looks like I got a new error:

InkedScreenshot_2_LI
InkedScreenshot_2_LI1216×396 85.2 KB

1 Like
#13

Just got the acme challenge working with webroot on the reverse proxy. Can you confirm for me:
If I set ssl verification with the certificate in the reverse proxy and then proxy pass the connection to the backend. The connection will be encrypted between client and reverse proxy. And unencrypted between reverse proxy and backend. (Within the same lan network).

Is there a possibility to use this certificate between backend and reverse proxy too? so There is a encryption from client to backend?

2 Likes
#14

It's possible to go either way depending upon your configuration. This is the same dilemma that people face when using Cloudflare. If you physically control the LAN and your backend devices have no publicly-facing interface, what's the idea of using https internally? Is there an application requirement? A little guy in a racoon mask bugging your network? :raccoon:

3 Likes
#15

Further to @griffin's point, you could do the same thing as some Cloudflare users and use a self-signed certificate which you somehow explicitly configure the reverse proxy to trust.

Well, Cloudflare's connection to your origin server is always going over public Internet links, not just over your LAN. So the dilemma is related but a little different, as I think you were suggesting with the raccoon. :raccoon:

2 Likes
#16

And yet Cloudflare offers their ridiculous "Flexible" option... :grin: The illusion of security: worse than the admission of no security.

2 Likes
#17

Yeah, I remember some conversations where people argued that someone (maybe browser root programs) should try to forbid Cloudflare from offering that option, because it would undermine users' ability to predict how well-protected their communications are. I think the counterargument was that someone operating a web service can always choose to share or transmit user data in some unexpectedly insecure way, and browsers can never do anything to guarantee that this isn't happening.

3 Likes
#18

Seems like they might as well just rename the "Flexible" option to "Padlock Deceiver". Their own excuse for having the option is almost as ridiculous as the option itself:

Use Flexible only as a last resort if you are unable to setup SSL at your origin web server.

3 Likes
#19

Thanks, will take care of client to reverse proxy ssl encryption at first.

I am physically in control of the LAN network so no problem in there.
There is no need or application requirement for reverse proxy to backend (lan) ssl communication. But I think that it's more about how crazy you want to set it.

Maybe a little for the :raccoon: in the garage running around the reverse proxy :stuck_out_tongue:.

3 Likes
#20

Have a look here for nextcloud configuration:
Reverse proxy - nextcloud
Besides the setting on the proxy, I had to enter in the nextcloud config.php
'trusted_proxies' => ['proxy IP here'],
in order to work.

1 Like