Nginx reverse ssl proxy not quite working / error: ui.panel.page-authorize.initializing

Hi,
I’m struggling to get the last steps of the nginx reverse proxy working as needed. I have an external ubuntu 18.04 server running nginx, with HA running on a RasPi. I have successfully installed certbot certs for the reverse proxy, and configured according to the HA documentation for reverse proxying:

map $http_upgrade $connection_upgrade {
default upgrade;
‘’ close;
}
server {
server_name hassio.fqdn;
listen 443 ssl default_server;
gzip off;
ssl_certificate /etc/letsencrypt/live/hassio.fqdn/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/hassio.fqdn/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/hassio.fqdn/chain.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
proxy_buffering off;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_pass http://hassio.local:8123/;
}
access_log /var/log/nginx/hassio.fqdn.access.log;
error_log /var/log/nginx/hassio.fqdn.error.log;
}

And have set the configuration of HA as:
http:
base_url: https://hassio.fqdn/
use_x_forwarded_for: true
trusted_proxies:
- proxy.ip

I consistently get an error as below:
[[localize(‘ui.panel.page-authorize.initializing’)]]

when I attempt to access via the FQDN, so I appear to be connecting, but not fully (ie I can successfully proxy http, and log-in, but not when connecting via https), however the certificate is valid, and signed, so the problem does not (I believe) appear to be there. Thoughts gratefully received…

Where are you getting hung up at? It took me a little bit to get it working too.

Does HA load properly? Are you able to hit it from inside your network?

Are you using the Domain or a Sub-Domain?

Did you add the proper settings in the sites-enabled area of Nginx?

Hi @techwithjake - I hit return on the question a little early, have given a little more background - I’m testing on my internal network, but I do get the same externally or internally.

Here’s a little snippet of my setup.
There’s things I’ve pulled for simplicity sake and privacy but this should work for you.

And here is my http config.

@techwithjake - thanks for this - I’ve had a quick look through, and while there’s a couple of minor differences, which I’ve now added, it seems to be pretty much the same as I have. I’ll spend a while longer looking in detail and reviewing to double check I’m not missing anything - I’ve had a few evenings looking at this now!
The one element which jumps out, is that I see you have is the API password in the HA config, but no reference in the nginx config - my understanding is that this is not needed?

I can confirm, having updated my config after reviewing, I’m still getting the same error (this is definitely presented by HA and not the proxy, as I do get the HA logo).

Correct. Everything I have in those snippets that pertain to HA are all I have. Only thing in the HA configuration.yaml file is the

use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - ::1

parts of it.

Can you hit HA properly inside the network by going to its internal IP? http(s)://192.168.XXX.XXX:8123?

OK - thanks for your help, it seems something else is likely happening here.
Yes, I can hit HA internally by local IP, and hostname, and can also proxy over http, but when I try to proxy over ssl I get the error detailed thrown up by HA (via different browsers, both on laptop and mobile device), and I’m not sure what other logs I can look at within HA (if any) to determine what the problem is.

Are you tyring to send https all the way through to HA? It’s much simpler I think to terminate SSL on the nginx and just use http internally to HA.

Anyway, here’s my config if it helps:

####################################################################
#
## HASS domain
#
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}
server {
    server_name hass.mysite.com;

    proxy_buffering off;

    location / {
        proxy_pass http://192.168.1.245:8123; # HomeAssistant server IP address
        proxy_set_header Host $host;
        proxy_redirect http:// https://;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }

listen 127.0.0.1:443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/hass.mysite.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/hass.mysite.com/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

include /etc/nginx/snippets/highsecurity.conf;

}
server {
    if ($host = hass.mysite.com) {
        return 301 https://$host$request_uri;
} # managed by Certbot

listen 80;
    server_name hass.mysite.com;
return 404; # managed by Certbot
}
  • Are you sure you need default_server in your port 443 setting (i.e. is this your only redirect/site on nginx)?
  • Try specifying the SSL port interface 127.0.0.1:443 rather than leave it at 443 (“all interfaces”)
  • I’d also change your proxy_pass http://hassio.local:8123/ entry to use the IP address of hassio to test

Thanks - will take a look.
I’m trying to terminate on nginx, and then pass through. Currently, to try to keep it simple, I am only redirecting one site. Name resolution is working internally, but I’ll certainly try these suggestions later today, and see how I get on!

That sounds like something is wrong with the IP Address for the domain. If it wasn’t working externally for the domain, it shouldn’t work internally properly either. Can you hit HA by using the Public IP address?

Can double check by putting the domain here; DNS Lookup Tool - DNS Tools - MxToolbox ; and using the IP Address it spits out. When I did it, the site loaded by HA complained about “Error: invalid client id or redirect uri”, which makes sense due to the fact I don’t have the IP Address in HA.

Internally I’m using hosts files on local system for testing, externally I have updated the A record on my DNS records (and I hit a HA page, just don’t get the login page as expected), so name resolution works for the FQDN from both externally and internally. The routing and name resolution does not appear to be the issue, it would appear to be related to proxying, and/or redirection I think, although given the fact I can proxy http traffixc successfully, I’m somewhat puzzled.

Mind sharing a screenshot of what you’re seeing externally on the page? Sounds very curious as to what’s happening.

When I first started the Proxy journey, I just couldn’t hit it. Never had any HA errors though.

No problem - see below!
image

Just noticed that you have Ngnix Access/Error logs setup. Anything in there of use?

Also for shits and giggles, what happens if you copy my Ngnix setup for “location / { }” and
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
under “listen 443”?

@gordonpm - Have tested:
Correct on default_server comment - I’ve rectified this - no difference.
I’ve tried the IP address of HA - no difference
I wouldn’t expect listening on the loopback to work, as I need to listen on the IP which will have inbound traffic. (I tested for the sake of completeness, and no server listening when I attempted the connection).
Thanks for the suggestions, though.

@techwithjake, the add_header element is catered for under this included line:
/etc/letsencrypt/options-ssl-nginx.conf
and currently is:
add_header Strict-Transport-Security “max-age=15768000; includeSubdomains; preload;”;
so I have been running with these options.

There’s nothing in the logging other than connections from my test (and details of the URL & redirect, and a few other connection attempts from the outside world, so nothing of note unfortunately.

I’d say PM the URL but I understand how scary that can be.

Have you had a friend try it on a completely different network and computer yet?

I’ve tried myself from different computers, and different networks - I’ll happily PM you the url, in case you can see more than I can - it looks like it must be related to the url re-writes / redirects, or HA itself, but I can’t figure that out at all!!