http is indeed working,
but i would like to have local also in https, is that why i need to set up a ‘hairpin’?
I have a nabucasa and local cert so that I can use ssl on local network. I use for internal network https//my.domain/
did you set the extern url also?
i have the same, but can not connect extern if i set a local url on https…
I have remote nabucasa link, my local wifi ssid and local https link. That all.
Can you connect to your local https with comp? Not nabu casa
Edit:
Prioritize internal Url is disabled.
“Prioritize internal Url is disabled.”
Think this is the problem! when i disabled this it works.
But why, and how do i see now if it uses the Local when on Wi-Fi or still the extern?
I don’t know I never bother my self with that question. You can try disconnect wifi on your router.
Do you see how it’s says enable this is you leave location off on the device? That’s the only part you need to be concerned with otherwise you don’t need to enable it as the app already does the url switching. Let the app do it’s thing without using the override.
Also the app requires a valid certificate and on a local IP it will never be valid.
2 Likes
Yes it will. I use dynu dns to get a cert. It’s renewed every few months and it’s valid. I use it for local ssl, in adguard etc.
If the dyndns cert has the same URL as the address in the calling URL, DNS resolves properly and that Cert chains up to a trusted root cert that is accessible and trusted by the device you’re using, yes. In almost all home use cases one of those falls apart… Make sure that’s completely true.
I resolve my dynudns hostname using dns rewrite. I resolve it as my ha ip name. As I can’t use dynamic dns due my provider settings I found my self a small workaround.
I get it. Just realize certs complicate stuff. Everything can be perfect from a connection standpoint and if the certs are borked, no connection. I ran a split DNS at home with my own fully functional three tier CA with an offline root for 10 years. What you want is entirely possible, it’s also a massive PITA from a support and maintenance perspective and why I don’t do it anymore.
Considerations when troubleshooting.
(all things are name resolution issues until proven otherwise - especially with SSL and certs)
The URL reported by the cert MUST match the caller to be valid. This gets especially tricky when playing stupid DNS tricks…
Ask it this way
When my client calls server at myurl.com from external what is the path and what does the server report. Resolve DNS for that and every single URL up the chain when chasing Cert Revocation Lists (CRL).
This usually works because it’s what most people setup to hit. It’s the internal that gets weird.
Now I’m hitting the internal site.
Do I use a different URL? If so, how is whatever I’m using as my reverse proxy /ssl termination point responding there? Same cert? If it’s a different URL with the same cert you’re broken right there.
I expect that’s your case as you said DNS rewrite (I promise I only cringed a little)
If I use the same URL but different ip space can I resolve all the things i need to to properly chase CRL with the network and DNS im currently connected to. (pull the cert and try to resolve and connect to every URL you see - especially those listed. In fields labeled CRL.)
If.you then can resolve and see all the certificates in the chain, is it a well known trusted root thats already trusted by your device? If no did you manually install the trusted root?
Your DNS can be perfect and all of that still matters.
Now you got me. Gotta switch from my mobile to comp.
My provider is using NAT on their routers. I have external ip but the same ip is shared with a bunch of other people. Maybe the obvious solution would be to use NAT hairpinning. I never set this up and I believe I can’t do it with my routers.
So I set myself a hostname and get a cert for it. My hostname do resolve to my provider external ip address, but I can’t access my comp as its behind NAT.
I set up of course nginx ssl proxy. For server I use my dyundns hostname with ssl certs provided by them to resolve on my internal home assistant ip. If I got this setup explanation right.
To make this setup work I configured adguard dns to rewrite dnydns hostname on my ha ip address.
If I want resolve my dynudns hostname from net it will resolve but the only thing you will get is external ip address of my provider.
From the inside it will resolve this hostname as my ha ip.
Your question are maybe too much for my knowledge. I’m not an expert in this matters. I don’t have any formal education on computer science. I learned everything on line.
Edit:
I use in adguard encryption. For a server i use my dynudns host name and Certificate chain is valid as well as ECDSA private key.
I used to do the something similar, i assigned the domain to my local network (something my router can do), and made a dhcp reservation for the host name, hence the dns resolve’s locally.
The only downside was I had to use https://ha.domain.mine:8123 local, and external without the 8123.
I enabled hairpin nat now, so no need to specify the port anymore
I don’t have this downsides. I can access it on https://mydomain/ and from http://homeassistant.local:8123/
But I believe I set up my host file right.
Ah, but then your SSL certificate must be on nabucasa.
I don’t have nabucasa, but I still use https:
The SSL certificate resides on my HA server local, and therefore http usage on 8123 is not possible, it can only use https (and therefore the dns must resolve to the address used for the SSL certificate)
So my only solutions are
- setup my own dns corresponding to domain certificate, and access it on https://ha.domain.me:8123 internationally
or: - setup hairpin nat and access it on https://ha.domain.me from anywhere
Butt as you said:
This would never work for you, as you can’t use port forwarding…
By the sound of it (AdGuard, NGINX), you quite over complicated things, unless you have a lot of guests on you local network, using https is not required at all…and due to being behind your isp’s nat, you can’t access HA from outside anyway (except using nabucasa. which is basically the opposite….it is HA contacting Nabucasa, and not the other way around)
Maybe I’m overcomplicating things. But I just wanted to have ssl cert on local network and access ha over ssl in local network. I know this isn’t mandatory and that you don’t have to do this but that was what I want.
I use nabu casa for remote access.
The setup I done works for me, providing me what I want.
And yes I want to have my own dns server so I can check what my devices are doing online.
In my opinion people take local network for granted. Well it’s local network it’s secure don’t have to do anything. But the case is that you have a lot of devices and you don’t know what those devices are doing. It’s like you have a bunch of people in your house talking different languages and you can’t understand them or their intentions.
The next thing I would like to do is to run mqtt over ssl and make it work with zigbbe.
For me it is working now,
SSL local for local connection
and NabuCasa is also auto with SSL when connected remote…
I set the url’s in the WiFi settings.
I have Nabu Casa Remote access and run a wireguard server in my LAN.
If I don’t prioritize the internal url will it use Nabu Casa or localhost url when I am not physically located near me home WIFI SSID? Is there no way to see which connection is being used?
if you dont enable prioritize internal then the app will use the internal URL only when connected to a home wifi SSID. Otherwise prioritize internal will always try the internal URL first even if it will fail.
you can see this in the companion app logs when either URL is being used
1 Like
Thanks. Here is the log entry in case anyone wants to verify:
UrlRepository: localUrl is: true and usesInternalSsid is: false