-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug] HomeAssitant SSL Support #189
Comments
I have a HA with https/wss, no http/ws used at all so I need this too. |
I did a quick'n'dirty workaround. I have HA as a docker on debian, installed Nginx to debian with a simple and minimal config to act as a ws to wss (http to http) proxy. Works fine. Nginx config:
|
@RC-Thoughts have you already tried connection with wss and get the same error? The integration supports wss connections and it has been confirmed working. But apparently not all TLS configurations (or http2) are supported. @BugRoger thanks for the link! HTTP 1.1 only in ALPN extension is already set, but maybe I've missed something else. Since I've updated rustls which required some refactoring (unfoldedcircle/integration-home-assistant@617466d), I'd like to retest everything before a new release, but I need to find the time to setup a reverse proxy first. |
@zehnm Yes, and "Web Socket Client" application (Microsoft Store, Windows 11) does connect with wss just fine. |
I’m using Traefik as reverse proxy. The config is pretty vanilla. wss connections do work of course. I tested with a chrome plugin. Other tools in my setup like esphome can also connect to HomeAssistant without problem. |
I've setup a test environment on a VPS with a public IP address. The Home-Assistant integration is working using wss, tested with the included v0.4.0 in the firmware and main branch with new rustls version.
http:
use_x_forwarded_for: true
trusted_proxies:
- 10.89.0.0/24
homeassistant:
external_url: "https://homeassistant.XXXXXX.ZZZ" Please check your configuration if you see any major changes which causes wss not to work. If we find the cause and it can be fixed with a client setting, then I can fix the Home Assistant integration. Nginx configuration files from LinuxServer as reference:
|
My HA is also using let’s encrypt and https only. |
FWIW, I also have my hass behind a traefik instance and was unable to connect to it from the remote using Everything else on my network goes via traefik and works perfectly. |
@wez What did you do to fix it? |
Question to all for whom it does not work:
I have a suspicion if it's a public DNS name: the external IP of your router is resolved and without NAT-loopback it fails to connect. |
Define same network. 😄 It's in a different subnet but routable. There's a MDNS reflector between subnets.
SNI to the reverse proxy
CNAME homeassistant.l48a.de > ingress.l48a.de. A ingress.l48a.de > 10.0.0.3, resolved by Google DNS
Neither. I'm just using google DNS everywhere 8.8.8.8. No NAT between remote and proxy.
Yes |
@BugRoger thanks for the information! |
Yes, i was too quick. Still same error with the middleware:
|
Yes
Regrettably, there are several IoT devices that I do not 100% trust not to sniff out credentials from my home network, either now or in the future, that have to run on this same network. Similarly, not everyone in my household is fully computer savvy and they are at higher risk of running with malware that may also decide to snoop on the network via their devices. I strongly prefer to use encrypted traffic even on the local network to avoid leaking credentials.
I have split DNS for a fixed name, but whether your stack is hardcoded to use public DNS servers, or respects the local DNS configured via DHCP, the name resolves to the same IP.
Yes, my network is IPv6 + IPv4, but this particular name does not resolve to AAAA.
Note that everything else on my network is capable of correctly resolving this name and talking to the traefik instance. |
I forgot to mention that the 1.4.8 firmware disables the fallback DNS (Cloudflare, Quad9, Google). This could resolve a few issues with split DNS setups where the Remote & HA are both in the internal network. After wakeup I've observed, that the fallback DNS were often used instead the configured ones with DHCP. Could someone post a Traefik configuration that I could try out? I've never used it and it would speed up getting to a working setup :-) |
I'm by no means an expert, but here's the gist of my configuration. This is my version: '3'
services:
reverse-proxy:
container_name: traefik
# The official v2 Traefik docker image
image: traefik:v2.9
network_mode: host
restart: unless-stopped
volumes:
# So that Traefik can listen to the Docker events
- /var/run/docker.sock:/var/run/docker.sock
- ./data/config.yml:/config.yml
- ./data/traefik.yml:/traefik.yml:ro
- ./data/acme.json:/acme.json
- ./data:/config-data Alongside it I have a This is global:
checkNewVersion: true
sendAnonymousUsage: false
api:
dashboard: true
debug: false
insecure: false
log:
level: ERROR
entryPoints:
http:
address: ":80"
http:
redirections:
entryPoint:
to: https
scheme: https
https:
address: ":443"
serversTransport:
insecureSkipVerify: true
# https://doc.traefik.io/traefik/observability/access-logs/
accessLog:
fields:
defaultMode: keep
headers:
defaultMode: keep
names:
Authorization: drop
providers:
docker:
endpoint: "unix:///var/run/docker.sock"
exposedByDefault: false
file:
# points to the `config.yml` file
filename: /config-data/config.yml
certificatesResolvers:
resolver:
acme:
# config here for Let's Encrypt.
# See: https://doc.traefik.io/traefik/https/acme/#certificate-resolvers
email: [email protected]
storage: acme.json
dnsChallenge:
# Config here for my DNS provider. I use DNS for this because
# I'm ok with public names, but this particular instance can only
# respond on the LAN, so it is not possible to use HTTP or TLS
# challenges.
# If you don't want to or can't use DNS challenges with Let's Encrypt,
# you can instead create and configure your own TLS certs directly.
# I'm not familiar with how to do that, but
# https://doc.traefik.io/traefik/https/tls/ should tell you This is http:
routers:
traefik:
entryPoints:
- "https"
# allow seeing traefik's dashboard at `https://traefik.YOURDOMAIN`
rule: "Host(`traefik.YOURDOMAIN`)"
middlewares:
- authelia
- https-redirectscheme
service: api@internal
tls: &TLS
certresolver: resolver
domains:
- main: "THISBOX.YOURDOMAIN"
sans: "*.YOURDOMAIN"
hass:
entryPoints:
- "https"
rule: "Host(`hass.YOURDOMAIN`)"
middlewares:
- https-redirectscheme
- default-headers
service: hass
tls: *TLS
services:
hass:
loadBalancer:
servers:
- url: "http://192.168.1.5:8123" # Your hass IP:port
middlewares:
https-redirectscheme:
redirectScheme:
scheme: https
permanent: true
default-headers:
headers:
frameDeny: true
browserXssFilter: true
contentTypeNosniff: true
forceSTSHeader: true
stsIncludeSubdomains: true
stsPreload: true
stsSeconds: 15552000
customFrameOptionsValue: SAMEORIGIN
customRequestHeaders:
X-Forwarded-Proto: https |
Is there an existing issue for this?
Description
My HA is runing behind a reverse proxy. The connection is using https/wss with signed SSL certificates provided by Let's Encrypt.
The HA integration does not support SSL. The error:
2023-11-12 10:06:51.429977 +00:00 intg-homeassistant INFO [2023-11-12T10:06:51Z WARN uc_intg_hass::controller::handler::ha_connection] Could not connect to wss://homeassistant.l48a.de/api/websocket: SendRequest(TunnelNotSupported)
How to Reproduce
Setup HA Integration using a wss:// URL.
Observe Internal Timeout Error
Expected behavior
Support SSL for HA Websocket Connection.
This might be a solution:
actix/actix-web#1069
System version
No response
What part of the system affected by the problem?
Integration
Additional context
No response
The text was updated successfully, but these errors were encountered: