When enabling HTTPS in the config, the certificate (chain) works fine with macOS Browsers (Firefox, Safari) and the Companion macOS app. But the iOS app complains that the certificate is invalid (NSURLErrorDomain -1202).
I guess this happens because I am using my own root CA.
I have provided the proper fullchain.pem, containing the certs for the server, the server CA and the root CA.
On iOS I also have provided all those certs in a profile using Apple Configurator and I have fully trusted the root CA certificate on iOS.
The server cert contains SANs for the DNS name used in the iOS and mac app for connecting internally.
(note: when connecting through an NGINX proxy this works fine as the NGINX proxy is using a Lets Encrypt certificate, no own root CA)
I already checked with TLS inspector: the trust chain order of the certificates is: server, server CA, root CA.
testssl.sh complains that the root CA cert is self-signed, which is fine if you have your own root CA. All the other stuff looks good.
If someone got HA Companion on iOS to play nice with his own root CA, let me know what you did and where were the pitfalls to avoid.
I don’t have a solution, but just replying to state I have the same problem. My root CA and HA’s server certificate are both installed in iOS, and the root CA is trusted. It would be really nice to have this working as it’s a pain to go through the browser.
any news about that? I have the same problem. When I log in through app it says: “The certificate for this server is invalid etc… NSURLErrorDomain -1202”.
On Safari I can log in and have a secure connection and see the full chain, so I doubt the certificate is invalid.
Is it maybe not possible at all to use the app with running own ca/sub/s? If yes, I wonder if there is a feature request yet.
no news on this. the dev team is unwilling to handle this in the app. they fully rely on the OS for this. iOS does not seem to handle this sufficiently on its own.
so far i resorted to use LE certs on the reverse proxy, but man, that sucks if you don’t use certbot.
Please don’t ascribe motivations you’re unfamiliar with. The latest beta on TestFlight includes 2 changes here:
Error messages for SSL errors during onboarding are more direct (expiration is >365d, etc.)
You can trust certificates which fail SSL validation otherwise
This beta doesn’t yet do either of these outside of initially setting up a server, but will eventually prompt if it encounters an error when running or when changing the URL to a server. You can delete your server and re-connect to it for the moment.
As laudable as this development is: I will always feel free to comment on what I have been told. Look at how old this thread is. Back then it was what it was and I was told that one would not take certificate handling on their own hands and wants the OS to handle it. And I will repeat it again, if someone asks.
Nevertheless, I am happy that this has changed. And I also totally understand the previous devs position - my grudge would be rather on the side of Apple, not being able to provide proper cert handling on the API. Even the Apple apps - it seems to me - do this handling on their own, and not all do it the same way…
I configured Duck DNS and Let’s encrypt, and this break LAN access also to me, i solve simply installing Dnsmasq as add-on, as far that i don’t install a dns in my home network. added a static entry on host:
DNS forword, IP of my router, or, if prefered google… or other
host: YOUR_ID.duckdns.org
ip: HA_IP
on my iphone, and android set DNS to manual an pointed to HA_IP and now work!
form internet pointing https://YOUR_ID.duckdns.org
from LAN pointing https://YOUR_ID.duckdns.org:8123