Companion App does not connect with bad SSL certificates

I set up my Home Assistant to be available outside of local network using Cloudflare, Cloudflare add-on and Let’s Encrypt addon. Certificates are created for my external address (domain) specifically.

Every time I try to connect to a local address of Home Assistant using a web browser, I need to click “Trust” in order to connect to the address because the certificate does not correspond to the URL. Home Assistant Companion just refuses to connect at all, and there is no option to “Trust” the certificate.

This raises two questions.

  1. Is there any way to allow local IP addresses to use HTTP?
  2. Is there any way to bypass the SSL error in Home Assistant Companion CEF?
1 Like

1- Using reverse proxy as nginx, you can still use home assistant local ip address without ssl and nginx will be taken care of ssl part for external connection.

2- limitation of underlying OS, nothing can be done for this.

no the app will not bypass any SSL errors, you must use a valid certificate which is not valid on a local IP address

First solution worked like a charm.

For anyone wondering:

  1. Install Nginx Proxy Manager from Home Assistant Add-On Store
  2. Configure it as in documentation
  3. In Nginx Proxy Manager Web UI, after creating a new user, go to HostsProxy Hosts → create a new host with the following configuration:
  • Domain Names: add your domain
  • Scheme: http
  • Forward Hostname: your Home Assistant local IP
  • Forward Port: 8123
  • Check Websockets Support

Then go to SSL Tab:

  • SSL CertificateRequest a new SSL Certificate
  • Check Force SSL
  • Check I Agree... at the bottom

If you want to keep your Cloudflare, click Use a DNS Challenge and configure it with your token.

  1. Edit your configuration.yaml file. Remove SSL mentions from html category and add the following:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24
  ip_ban_enabled: true
  login_attempts_threshold: 5
  1. Reboot Home Assistant.

This steps made it possible to connect locally without SSL and externally with SSL.

Cheers!

4 Likes

Hi, I’m trying to solve the same issue with your suggesion but when putting my local ip in the domain names, nginx is getting me an error “Requested name 192.168.178.11 is an IP address. The Let’s Encrypt certificate authority will not issue certificates for a bare IP address”

what am I doing wrong?

Not what the instructions say.

Your IP goes in forward hostname. Your domain goes in domain.

I was really excited to try that, but received an “internal error” message right from the first try.
The log showed:

too many failed authorizations recently: see Failed Validation Limit - Let's Encrypt

Which is a bit puzzling, considering I just tried it for the first time.
I’ll appreciate any insights on this!

I have a pfsense router and use HAProxy for all my certificates and forwards. Has anyone tried using HAProxy for this? I got to the point where the companion app says that I have certificate mismatch.

Hi guys, I have the same issue ang I hope you can help me to solve it.
Im trying to use tailscale instead of duckdns + port forwarding.
I can connect my HA remotely while using the web browset, but while tryong to use the HA app I got a certification error.
I tried to follow the instructions above but Im not sure what should I add as the domain.
Thanks

1 Like

Hi there! Did you find a solution? Same issue here. Although I also got this error message:

“Some challenges have failed.”

And when I go through the steps again, it says that domain is already registered! Looks like it god registered on Let’s Encrypt, although the whole process failed and settings were not saved.

Thanks!

Sorry, I stopped working on that so I have no new news.
I moved to cloudflare and at the moment I have no SSL for the local traffic.

1 Like

Thanks anyway! I fixed it deleting all https related config on configuration.yaml. That was blocking the addon somehow. Looks like SSL needs to be handle either from the config itself or the Nginx Proxy Manager addon.

For my home setup[1] this is the same recurring “SSL handshake” showstopper problem, when connecting from the internet on my phone, using the Home Assistant Android app and Chrome on Android.

However, I’m able - thankfully - to connect with Midori on Android.

Does anyone have an idea why the Midori does accept the SSL cert just fine, but HA and Chrome apps do not?

[1] home setup

  • HA img on RPi4.
  • Nginx, LetsEncrypt and Cloudflare add-ons.
  • DynDNS updated hostname.
  • Internet connections use HTTPS, local uses HTTP.
  • Cloudflare caching and security.
  • On internal, local RFC1918 network the HA, Chrome, Midori apps connect successfully to HA.
  • From the internet, only the Midori app connects successfully to HA.

My options for grey/dynamic ip

  1. register domain name from keenDNS
  2. allow remote access in the “Access to web applications” section (http, tcp/8123)
  3. copy your 4th-level domain name to HA->config->network->hostname(top section of the network settings, just domain without http://)
  4. Optional - i did it at the same time with step 3, so don’t know if it’s needed.
    set URL-address for internet - https://YOUR_DOMAIN_NAME and for LAN -
    http://YOUR_LOCAL_IP_ADDRESS
    Works fine for me with ip address in LAN and domain name(use https:// prefix) with HA companion for android.

What is this IP address you put in the configuration.yaml: 172.30.33.0/24 ???

Hi, I don’t think the solution to this thread actually works. It’s all fine if you connect from outside, but if your server is behind a firewall you’re basically constrained to use http only. If you try https (with all the reverse proxy stuff enabled) there’s still a certificate mismatch because your domain name (for which the certificate is issued for) points to a different address, since you’re using a local (e.g. class C) address.

IMHO what’s missing here is a checkbox in the android app to ignore a bad certificate. The alternatives we have are: 1. unencrypted and 2. encrypted with a public IP (with or without reverse proxy tricks). I believe we’re missing option 3, which is in the middle security wise, to allow for encrypted traffic without checking the certificate. Yeah, I know it gives a false sense of security, but it’s better than no encryption at all (which is allowed). Are we allowed to ask for this feature in the app?

Thanks!

no we will not be adding this too many users dont know what it means. Use a reverse proxy to handle the certificate or consider creating a self signed certificate and import it to handle your local use case.

in terms of the companion app certificates MUST be valid, no exceptions.

edit: also Googles recommendation (which the app does follow) is not to proceed for any SSL errors

https://developer.android.com/reference/android/webkit/SslErrorHandler#proceed()

Just found out, how to use local SSL with the app and also get rid of all the browser saftety warning for your local sites.
All you need is a CA and a server certificate. I used my pfSense to generate the certificates and nginx proxy manager as a proxy.

  1. Create a CA (with pfsense or something else)
  2. Create a server certificate using the CA and the HA FQDN as common name (eg homeassistant.example.lan)
  3. Download the CA cert and install it on your phone settings (search in android settings for cert installation)
  4. Download server certificate and key
  5. Upload both to NPM and asign them to your proxy entry (it hast to be also homeassistant.example.lan=
  6. Now you should be able to access HA by app.

As an extra: When adding the CA.crt in your webbrowser settings, the connection to HA is marked as secure with no safety prompt anymore.

Another extra: When repeating steps 2-5 for all other local webservers, you get rid of all these annoying security warnings, because the CA is trusted and all generated SC are also trustet.

EDIT: May it was too late yesterday. The warning in the browser appeared again. But the app is still fine.

Sorry but I don’t get it: does this mean that Home Assistant prefers passwords to be sent cleartext to an unverified server (http) than encrypted to an unverified server (https+ignore_cert)?
Going for “safer” defaults is exactly for users that don’t know what this means; SSL is an extra layer of security that should be welcome over cleartext passwords. Ignoring certs is not good, of course, but it’s better than nothing. I think defaulting to http is a bad choice, and certainly not state of the art: most self-hosted services you find around come with https+ignore_certs as the default.

I’m sorry to insist: please kindly reconsider this!!

if you provide a valid SSL certificate teh app will not complain, even with a self signed one, just need make sure you create a valid one that you import correctly to the device.

so yes we will never proceed with any SSL errors as they are preventable