About Letsencrypt behind a reverse proxy


#1

I have let’s encrypt installed in a virtual machine behind a nginx reverse proxy. Is it OK ?
I think if there reverse proxy can always pass through request and response between Let’s encrypt and web host. It should be OK. But Is there any example about how to proper configure nginx reverse proxy to make it able to pass all Let’s encrypt needed to the real host?

I google a lot and couldn’t find an example. Or maybe this architecture is not workable with Let’s Encrypt?


#2

It should be workable if you have your reverse proxy setup correctly to allow it passthrough access to ./well-known there is lots of examples all over the web. Why do you not rather just use Nginx as a web server and avoid using it as reverse proxy for Apache I assume? Nginx is super solid, super secure, super fast and extremely robust.


#3

yes, I use nginx web server as well. it behind a nginx reverse proxy.
and also I pass through all http and https to the web server. So I can get Letsencrypt certification installed.
But the thing is that, it won’t work. The browser will have problem loading page because of secure connection failed.

I think the problem is the nginx reverse proxy won’t act as pass through agent for all https traffic.
when a client send https request it was passed to the true web server. and true websever will response to the client’s request. something interrupted because of reverse proxy.

what I expected is nginx reverse proxy can act as trassparent agency with ssl encrypted contents.
here’s my configuration, I don’t know if I need to add more configuration to make it work.

server {

listen 80;
listen 443;
server_name myserver.mydomain.com;

  location /.well-known {
     proxy_pass http://myserver.mydomain.com/.well-known;  
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }

location / {
proxy_pass https://myserver.mydomain.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}


#4

Yes, with a configuration like that, the frontend Nginx needs to be configured with the certificate and so forth, as it’s decrypting and handling the TLS traffic.

This is likely the best option. Have the frontend terminate TLS, and use unsecured communications with the backend, or reencrypt it.

You can use the ngx_stream_proxy_module to proxy arbitrary traffic without decrypting or otherwise meddling with it.


#5

LE doesn’t require a valid https connection for validation. it can use http , and i think it can use an invalid/self-signed cert for the validation phase.

you can proxypass as above http, or just proxypass to certbot running on the same machine, by specifying the port with a commandline arg (ACME will connect to port 80/443, but nginx can proxy it to port 8080/8443/etc

the nginx config above won’t work for ssl, because you don’t have any ssl directives on: your browser is trying to talk ssl, but nginx is talking https.

  https://certbot.eff.org/docs/using.html#certbot-command-line-options

  --tls-sni-01-port TLS_SNI_01_PORT
                    Port used during tls-sni-01 challenge. This only
                    affects the port Certbot listens on. A conforming ACME
                    server will still attempt to connect on port 443.
                    (default: 443)
  --http-01-port HTTP01_PORT
                    Port used in the http-01 challenge.This only affects
                    the port Certbot listens on. A conforming ACME server
                    will still attempt to connect on port 80. (default:
                    80)

#6

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