It’s a simple addition to make I feel. Please give us a tick box on the mobile app login screen to trust self-signed certificates if we choose. I recently tried to connect to my new HASS OS server from the Android app and my self-signed cert was rejected. I converted the HASS .pem certs to .pfx and these were installed into the Windows trusted certs store fine and browsers like Chrome and Edge work without warnings on the web UI. Yet when I install the same cert into Android’s user credentials store i’m still rejected by the HASS mobile app. I see the certificate is not listed under ‘User’ within ‘Trusted Certificates’ and I think this is because I needed to also create a CA. If the HASS developers can give us a manual self-signed SSL trust check box then we don’t even need to mess about installing certs into mobile devices, let alone setup CAs.
Case for the importance of self-signed certificates:- I remote access to multiple services I self-host at home. I don’t wish to publish everything through my firewall and I don’t trust the likes of Cloudflare or anyone else to have sight of all my traffic. The best and only solution I want is a VPN that gives me secure access to everything, no messing about. I don’t want to be paying for and configuring public hosted DNS and trusted certificates. I just need a dyn-dns service and my WireGuard client / server. Self-signed SSL is perfect for my needs. Why is that so troublesome for the HASS mobile app?
Disclaimer:- If I’ve missed something here I welcome any helpful comments or feedback. I’m new to HASS (absolutely loving it by the way! I think the team have done an amazing job).
It is not enough to trust the certificate.
You will also need to trust the Certificate Authority, which means your server and that requires it to be online and available publicly.
Even then Android is a tricky beast to please, because allowing the addition of trusted third party certificate authorities opens up for all kinds of bad tricks by malwares.
Yes, that’s what I was saying. Although if i’m using a VPN it can find the CA internally from mobile clients but CA hosting is just another additional pain I could do without. I’m also a bit confused about why Home Assistant force appends ‘local’ to the internal host name. It means you can’t create a certificate that works for both internal and external addresses? I later discovered that NGNIX Home Assistant SSL Proxy was the easiest way to run SSL but i’m not very happy that I have to use a publicly trusted Lets Encrypt cert that expires every 3 months. I wanted to use a wildcard but in truth, using it for anything other than HA means you need to have certbot auto-renewing it continually which isn’t suitable for everything. I have a public DNS record for the new Let Encrypt cert that points to an internal IP
No, you don’t have to. Put your certificate and private key into /usr/share/hassio/ssl and put the name of the files into the addon configuration field.
Obviously you will need to renew the files every year since that’s the maximum length the browsers nowadays allow.
The problem is really not adding the certificates, but to verify them.
In order to verify them the OS needs to contact the Certificate Authority of each Certificate in the Certificate Chain.
Am self-issued certificate will typically only have one other Certificate in the Certificate Chain and that is the one of the Certificate Authority, so the OS just needs to check with that one.
This is easy when on a LAN with a server to act as Certificate Authority, but if you are on the internet, then you need to make that server available there too.
And of course you need to add the Root Certificate of the Certificate Authority to the OS’s certificate list.
This is only true if the certificate includes an OCSP extension, or a link to a CRL Distribution Point. Neither of these make any sense in the context of a self signed certificate where a breach of the leaf certificate is inherently a breach of the root that would be able to forge a CRL or OCSP message.
Even when a CDP would be possible (e.g. when someone is creating a separate CA cert for their internal systems), very few home users bother and far fewer would go to the trouble of standing up OCSP infrastructure.
When a certificate doesn’t contain a CDP or OCSP, it is validated purely on the signatures, which can be done entirely offline.
The credential store is for storing certificates that you use in place of a username & password, it is not relevant to your use case. You need to install into the CA store. You don’t need to create a separate CA certificate, a self-signed cert is both the CA and leaf cert.
True, that is how it should be, but Google and Mozilla seems to have a different opinion on that on Android at least.
I do not know if they use CDP or OCSP, but they are really hard to get to trust self-signed certificates without some warning popping up and requirement for accepting the risks, at least in the Chrome and Firefox browser.
I do not really know how HA’s companion app works though, since I run it without encryption, but through an encrypted VPN connection.
In reality the devs can add an option inside the Home Assistant app to force untrusted certificates. It’s still better than using an un-encypted connection (HTTP).
I personally know 3 people that have set up Home assistant, but that couldn’t get https running because of this issue, so now they opt to just use unencrypted public access to their home assistant.
So basically, what I am saying, is that because the ‘force use of untrusted certificates’ options is not available, the result is that some people have a much much less secure home assistant. Thus, if you add the option to force untrusted certificates you are actually making the app more secure. Because then people will actually use HTTPS instead of HTTP.
I don’t want to register a DuckDNS account. So I am also using a self signed certificate (untrusted). But instead of using the Home Assistant app I just use Chrome and install a shortcut on my phone. Chrome allows you to use an untrusted certificate.
So, because the option of ‘force untrusted certificates’ doesn’t exist on the Android app, it causes some people to opt for way less security using http, and for other people to just not use the app at all.
A DNS, not even an SSL protected DNS, will help you protecting HA with SSL. A VPN might, but that is a different Adguard product. So are you 100% sure you didn’t just open up HA to the internet unsecured?
You can use Let’s Encrypt with a DNS challenges provider to get a certificate and then use that internally.
This is my approach for it with Cloudflare as DNS service.
The discussion about self-signed certificates is that they open up to certificates for domains without certifying the ownership, which is the fundamental reason for a certificate.
I am not even sure the devs can just allow self-sgned certificates, because I think that part is included in the Google Play Services that the Android App use and Ithink Apple has the same on iPhone.
as far as i remember is that certificate is for an adress like domainname.duckdns.org . it is not for ip adres in lan.
so i can not call my HA sever on LAN via https.
Thus, using AdGuard with dns serwer i set to forward all calls to domainname.duckdns.org to my server ip adress like 192.168.1.100 … and it works.
now i have companion app in my smartphone and it connects to HA from LAN and WAN
I think this feature request should be implemented not because the solution is perfect, but because HA currently has the default set to the worst possible security protocol, and because this is not state of the art as a self-hosted local service. Nowadays, any self-hosted service you deploy comes with https enabled by default with no-cert-check on the client, and instructions on how to improve it.
Because HA does not allow untrusted certs, it’s forcing users to either spend their time setting up something that’s intrinsically complex, or send their passwords unencrypted over the wire from the companion app.
This thread is about the companion apps, which might have limitation imposed by the underlying libraries used.
This thread is not about the HA server application.
The HA server application is prioritizing convenience over security.
The decision to not use HTTPS on the HA server application is probably, because not all integration and devices can use that, so these will be impossible to use.
HA could implement a proxy to make it possible to use both HTTP and HTTPS, but that would require even more code to maintain, and it is a code that is already available in the form of the standalone product called NGinX among others.
There is really no need to maintain that code, when it is already available, and not required for the operation of the HA server application.
If you want to go the secure way, then VPN is the way to go and not portforward with or without HTTPS.
As said before HA is about being as compatible and convenient with as much as possible, which will mean security will take second place at times.
Relying on HA as the first line and only of security is not best practice, because HA will have security issues at times and already had it in the past.
It might be required to choose a lower security level for some setups, like connecting to many other home automation systems, like Google, Amazon and Apple, but again HA allows this based on the priority of convenience.
I think there’s a misunderstanding. I am not talking about the server application, but about the Companion App. Please replace HA by HA Companion App in my previous message.
Having HA Server with SSL with self-signed certs is simple enough; agreeably, this could be the default in the HA Server, too… maybe the source of the misunderstanding, but probably for another thread.
This is a chicken/egg problem. The companion ap is the most important client; together with the browser, I’m ready to bet one beer they both cover >90% of the connected clients. Being such important client, if it does not support self-signed certificates, it forces the server’s default to be http, and forces the credentials of the main client to travel unprotected. A simple virus sniffing your network can get a hold of these credentials. Please allow the client to go via https, and we can worry about the server’s default at a later stage.
NB: for what is worth, most mobile apps accept not-verified certificates. Synology Drive, OpenVPN, CalDav… essentially all the Apps I use in my local network, except for the HA Companion. Surely there must be a way in the underlying libraries used to allow for that, I’m sure most apps don’t rewrite the SSL client libs.
Not at all.
You can still use CA signed certificates and the support is widely available with many different setups.
HTTPS might secure your communication with a high standard, but the authentication is not at equal heights.
VPN provide both good encryption of the communication and good authentication and no need for HTTPS then.
