reverse proxy https not working
Lucas Rolff
lucas at lucasrolff.com
Sun Aug 26 11:42:48 UTC 2018
> 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-bounces at nginx.org> on behalf of "Jungersen, Danjel - Jungersen Grafisk ApS" <danjel at jungersen.dk>
Organization: Jungersen Grafisk ApS
Reply-To: "nginx at nginx.org" <nginx at nginx.org>
Date: Sunday, 26 August 2018 at 11.29
To: "nginx at nginx.org" <nginx at 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 <lucas at lucasrolff.com>
To: "nginx at nginx.org" <nginx at nginx.org>
Subject: Re: reverse proxy https not working
Date sent: Sun, 26 Aug 2018 08:47:03 +0000
Send reply to: nginx at 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-bounces at nginx.org> on behalf of "Jungersen, Danjel -
> Jungersen Grafisk ApS"<danjel at jungersen.dk>
> Organization: Jungersen Grafisk ApS
> Reply-To: "nginx at nginx.org" <nginx at nginx.org>
> Date: Sunday, 26 August 2018 at 10.33
> To: "nginx at nginx.org" <nginx at nginx.org>
> Subject: Re: reverse proxy https not working
>
>
>
> From: Lucas Rolff <lucas at lucasrolff.com>
> To: "nginx at nginx.org"<nginx at nginx.org>
> Subject: Re: reverse proxy https not working
> Date sent: Sun, 26 Aug 2018 08:19:28 +0000
> Send reply to: nginx at 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-bounces at nginx.org> on behalf of "Jungersen, Danjel -
> > Jungersen Grafisk ApS"<danjel at jungersen.dk>
> > Organization: Jungersen Grafisk ApS
> > Reply-To: "nginx at nginx.org"<nginx at nginx.org>
> > Date: Sunday, 26 August 2018 at 10.13
> > To: "nginx at nginx.org"<nginx at 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180826/e8554087/attachment-0001.html>
More information about the nginx
mailing list