I’m also using Let’s Encrypt and Duck DNS. Local access works fine. Remote access works fine on my laptop. Access from the (Android, in my case) app doesn’t work. So, basically the same symptoms.
I REALLY need to make a video explaining how DNS and certificates actually work. This topic seems to be posted here at least 3x a week.
If you have a certificate installed ON your HA server, your internal and external URLs should be the same. Do not use the IP of HA, do not use homeassistant.local, none of that. The FQDN portion of the internal URL should be the exact same as the external.
Then, install the DNSMasq add-on. Create an A record for whatever your external FQDN is, and provide the internal IP address of your HA server.
Then, change your DHCP server to hand out the IP address of your HA server as the DNS server for your internal network.
As for accessing it, on your companion app set the external URL to be https://< myHAserver.com > and the internal URL to be https://< myHAserver.com:8123 >. Or, you can do away with that external NAT and simply use 8123 for both, which is marginally less confusing.
Problem solved. No more of this hairpinning the firewall nonsense, and no more certificate mismatches.
That really depends on how the setup is.
If no port is given, then port 443 is assumed with https.
But I agree a video on how DNS relate to IP addresses and how certificates do not would nice.
Correct on both counts, fixed my response. Thank you for that! Been a while since I had actually looked at that part of my config. LOL
That video has actually been on my to-do list for quite a while now, and the script is partly written already. Just haven’t had time between work and other videos. Need to spin up an azure lab to get all the screenshots of a DNS server since I think seeing the whole thing visually is what people need; looking at a bunch of text for A and CNAME records isn’t likely to make it “click” for most people. If you have any pointers or suggestions for specific things you think should be included in that video, please feel free to PM me (I don’t want to clutter up this thread).
Thanks!
Before you re-instal and re-configure your whole setup, drop the device on which you getting the error from the network.
I hit reconnect for my iphone in the wifi management app and it got a new fresh lease and everything works now…
I almost re installed homeassistant 
Seems this was just an accidental fix. Got the issue again and can’t fix it with the network drop anymore
My external url is set to “cloud”. Thus can’t replicate the inetrnal to the same.
Also the error sometimes appears, sometimes not and I am able to use HA on my iOS device on local nezwork just fine.
Judging from this - the companion app settings are OK, there is something else at play - something on the network itself - any ideas?
That’s why the first response with router routing the comm as direct local made most sense…
Hi, just wondering — did you ever get round to posting a video as I’d love to really get my head around this. I get the same invalid certificate note whenever I try to access via local IP or homeassistant.local so I just default to the public duckdns address when at home and out and about (which as I understand it, is what you’re suggesting in your second paragraph).
But when I check my duckdns logs I see this:
[09:13:59] INFO: Renew certificate for domains: XXXXXXX.duckdns.org and aliases:
# INFO: Using main config file /data/workdir/config
Processing XXXXXXX.duckdns.org
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Sep 27 04:37:38 2024 GMT (Longer than 30 days). Skipping renew!
So I’m not sure what I need to address, but am also having some trouble with setting up MQTT and inputting the correct Broker Host details, and wonder if this might be behind that, so love to resolve if poss!
It is working as intended.
The free certificates are only bound to a public domain name and that means it will only be valid when using that name,
There are certificates that can be bound to public IPs too, but these are rarely free and your internal IP is not public IP.
Your internal IP is a one that starts with 192.168 or 10. or 172.16
This is IP ranges that have been reserved for internal use and pretty much everyone use them.
That means if several users make certifcates for these IPs, then they can set up systems to pretend to be each other servers, which is exactly what the certificates are meant to prevent.
The same goes for the .local domain.
It is reserved domain name for the mDNS protocol, a serverless DNS version.
Everyone with a mDNS service will likely use that domain, so same issue.
Your log output is also as intended.
It just tells you that it you have not made changes and that the certificate is still valid and good.
It will first renew the certificate when the validity is less that 30 days.
To solve your issue with local versus public traffic there are different solutions.
- Use NGinX SLL Proxy for external HTTPS access and then use HTTP internally
- Buy a public domain and set it up on an external DNS service with your internal IPs (It is generally not considered a good idea to list your internal servers, but it work)
- Buy a public domain and set up an internal DNS server with it (This requires knowledge about how DNS services works, but is the best solution, and is often called split-DNS)
- Run a DNS masquerading server, which is a split-DNS service, but it can be made to rewrite only certain host entries, so you do not have to own a public domain, but can use service that share the domain name out to users, like DuckDNS. (This still require knowledge about how DNS services works and probably more than normal split-DNS, because you need to understand the setup of the shared domain)
I made a video about DNS, but haven’t gotten to the one about certificates yet. The DNS one focused primarily on A record vs CNAME, and subdomains, but the basics are there.
2 Likes