> Both did the trick, but which one is better? I personally prefer the $request_uri one because it’s very clear exactly what it does.
> I think I read somewhere that nginx would connect unencrypted to the backend, > and do the encryption / decryption, is this wrong then? Nginx will connect the way you’ve told it to connect, if you’re connecting to a http backend, it will do plain communication over http – if you’re connecting to a https backend, it will establish a secure connection with the backend, and decrypt the response before encrypting it again when going to the client. > It works on some of my other domains, so is this just an exeption? > What I really ask is this: Should I change my other domains also, or should I > kepp them as they are as long as they work? I would change it for consistency across your configs, but that’s my opinion – if it works then it’s all OK anyway, I don’t know the specific case when it will and will not work – so I by default set $request_uri because it works in 99% of the cases, and I’ll only modify it if another behaviour is required. Best Regards, Lucas Rolff From: nginx <nginx-boun...@nginx.org> on behalf of "Jungersen, Danjel - Jungersen Grafisk ApS" <dan...@jungersen.dk> Organization: Jungersen Grafisk ApS Reply-To: "nginx@nginx.org" <nginx@nginx.org> Date: Sunday, 26 August 2018 at 11.29 To: "nginx@nginx.org" <nginx@nginx.org> Subject: Re: reverse proxy https not working Thanks !!! proxy_pass https://192.168.1.3; proxy_pass https://192.168.1.3$request_uri; Both did the trick, but which one is better? I will now try to re-enable all the "force encryption" settings. And closing firewall ports to see what I can avoid having open. I'm a bit of novice at proxies, so please be patient :-) I will read the documentation sections you mentioned. I think I read somewhere that nginx would connect unencrypted to the backend, and do the encryption / decryption, is this wrong then? It works on some of my other domains, so is this just an exeption? What I really ask is this: Should I change my other domains also, or should I kepp them as they are as long as they work? It sounds like you recommend removing the "/" on all sites(?) A current typical setup: server { server_name www.printlight.dk; server_name printlight.dk; location / { proxy_pass http://192.168.20.3/; proxy_set_header Host $host; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/printlight.dk/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/printlight.dk/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { if ($host = www.printlight.dk) { return 301 https://$host$request_uri; } # managed by Certbot if ($host = printlight.dk) { return 301 https://$host$request_uri; } # managed by Certbot listen 80; server_name www.printlight.dk; server_name printlight.dk; return 404; # managed by Certbot } Best regards Danjel From: Lucas Rolff <lu...@lucasrolff.com> To: "nginx@nginx.org" <nginx@nginx.org> Subject: Re: reverse proxy https not working Date sent: Sun, 26 Aug 2018 08:47:03 +0000 Send reply to: nginx@nginx.org > > The vendor recommended me to use a reverse proxy.... > > Ideally the vendor should have a working config in that case, but, I do see a > few things that can > be an issue. > > You’re serving https but proxying to an http backend – depending on how the > software works, a > lot of the reverse URLs that is sent back, might be linking to http:// > instead of https:// > > This in itself can break a lot of functionality, you might want to try to > proxy to an https backend > – this might require that you create a self-signed certificate on the backend > (can be valid for 10 > years) – the backend software itself, if it has a way to enable “https”, > you’d have to set this as > well. > > I also recommend removing the / (slash) in the end of the proxy_pass, this > will pass through the > request URI from the client, as per documentation: > > > If proxy_pass is specified without a URI, the request URI is passed to the > > server in the same > form as sent by a client when the original request is processed, or the full > normalized request > URI is passed when processing the changed URI > > Alternatively do proxy_pass http://192.168.1.3$request_uri; or proxy_pass > https://192.168.1.3$request_uri; > > Additionally, if your software uses Location or Refresh headers, then you > might want to look > into proxy_redirect ( > http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect ) to > rewrite this on > the “return” to the user. > > Best Regards, > Lucas Rolff > > From: nginx <nginx-boun...@nginx.org> on behalf of "Jungersen, Danjel - > Jungersen Grafisk ApS"<dan...@jungersen.dk> > Organization: Jungersen Grafisk ApS > Reply-To: "nginx@nginx.org" <nginx@nginx.org> > Date: Sunday, 26 August 2018 at 10.33 > To: "nginx@nginx.org" <nginx@nginx.org> > Subject: Re: reverse proxy https not working > > > > From: Lucas Rolff <lu...@lucasrolff.com> > To: "nginx@nginx.org"<nginx@nginx.org> > Subject: Re: reverse proxy https not working > Date sent: Sun, 26 Aug 2018 08:19:28 +0000 > Send reply to: nginx@nginx.org > > > Which functions do not work? > Thats a bit hard to say, but I'll try.. > > It's a print production system. > 1 part is approval of pages in a job. > > When I try to open a page for approval the system should open up the page in > large size. > That does not happen. > The thumbnails on the side works. > And as stated, when I do the same thing when connected via http, there are no > issues. > > > > > Be aware some software (WordPress being a good example) doesn’t always work > > with > reverse > > proxies that easy. > The vendor recommended me to use a reverse proxy.... > > > > > Could you possibly include your nginx configuration? Especially your proxy > > parts. > > server { > > server_name portal.printlight.dk; > > client_max_body_size 1000m; # (I tried with and without this line) > > error_log /etc/nginx/log warn; > > location / { > > proxy_pass http://192.168.1.3:80/; > > proxy_set_header Host $host; > > } > > listen 80; > listen 443 ssl; # managed by Certbot > ssl_certificate /etc/letsencrypt/live/portal.printlight.dk/fullchain.pem; > # managed by Certbot > ssl_certificate_key > /etc/letsencrypt/live/portal.printlight.dk/privkey.pem; # managed by > Certbot > include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot > ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot > > } > > > > > > From: nginx <nginx-boun...@nginx.org> on behalf of "Jungersen, Danjel - > > Jungersen Grafisk ApS"<dan...@jungersen.dk> > > Organization: Jungersen Grafisk ApS > > Reply-To: "nginx@nginx.org"<nginx@nginx.org> > > Date: Sunday, 26 August 2018 at 10.13 > > To: "nginx@nginx.org"<nginx@nginx.org> > > Subject: reverse proxy https not working > > > > Hi there. > > > > I have a setup that almost works. > > :-) > > > > I have a handful of domains that works as they should. > > Traffic as accepted and forwarded to my apache on another server (also in > > dmz). > > I have setup certificates with certbot. > > I have green (encrypted) icon on my browser when I visit my sites. > > > > 1 site is running on my green network. > > When I connect to that site all seems to work. > > However, certain functions fail, but only when connected via https. > > If I change the setup so that port 80 is not redirected to 443, everything > > works as long > as I > > stay with http. > > As soon as I chenge the url to https:// some functions fail. > > I have tried but cannot understand the debug log. > > > > I don't see any hits on my firewall. > > > > Any clues? > > I will be happy to send config and logfiles, but I'm not sure exactly what > > to send. > > > > Best regards > > Danjel > > > >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
