Self-signed SSL certificate trust option for the mobile app login

Feature Requests
, ,
#1

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).

#2

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.

#3

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 :upside_down_face:

#4

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.

#5

the android app already supports user added certificates, you just need to add it

#6

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.

#7

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.

#8

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.