Self Signed certificate for external access via non-DuckDNS domain (IE: Bare IP address)
I’ve got 1 and 2 working with NGINX SSL Proxy and yadda, yadda. I can’t get seem to get 3 working. My employer is blocking *.duckdns.org and I like having a Home Assistant tab open while I work. Since my IP changes extremely rarely I figure this might be reasonable. Currently I get ERR_SSL_UNRECOGNIZED_NAME_ALERT when I try, which makes sense. LetsEncrypt doesn’t issue certs for bare IPs, and so the name doesn’t match the certificate.
I was playing with NGINX Proxy Manager, and perhaps I need to disable NGINX to do this, but I’m sort of flailing around and would appreciate it if someone could point me in the right direction. I really know very little about NGINX, I’ve gotten this far with the help of tutorials and some experimentation. Anyone have any tips/pointers on the right way to do this?
If you can not access through your IP address now by accepting the risk in the browser, then you will not be able to do it with a self signed certificate either, because that has to be installed in your certificate store on your machine to be accepted, which for sure will be locked down.
Most likely the culprit here is Nginx. You should be able to get the HA web UI with a self signed cert as long as you add the exception on the browser, if the employer policies let you do it. Are you using Nginx for security purposes?
I believe I can get passed the self signed cert at work. We use them on our development machines all the time, so that shouldn’t be an issue.
I’m using NGINX because I wanted local access as well as secure external access. When it was just DuckDND+LetsEncrypt I was unable to access my Home Assistant instance locally period. Adding NGINX enabled me to access it (insecurely) locally.
External access is nice for Alexa and Google Home, as well as device tracking, but for devices inside the home network I see no point in making the external round trip.
I may be missing something, but it surprises me that a common solution on the forum to something as trivial as internal access using a public domain name is standing up an Nginx server in front of HA. Often the problem with local access using DuckDNS+LetsEncrypt is that some routers don’t handle as desired internal requests directed to their external IP. You’d expect that the router would use the port forwarding entry to send the request back to the internal host (called NAT hairpinning). Even if it works, for security reasons the best option is not to go through the WAN IP if you are on the LAN, but go directly to the internal HA IP. This is achieved with split-horizon DNS. Which means using a local DNS server, which can resolve the external HA domain name to the internal IP.
Use another DNS provider that is allowed by your employer. Cons: You may have to pay for the service.
Replace the certificate with one containing the IP, issued by your own CA. Cons: You’d have to install the CA on all devices if you don’t want their apps to complain about the cert. Some apps may choose to ignore user-installed CAs, and installing one won’t be possible on iOS unless you have Apple Mobile Device Management, which is not free.
Replace the certificate with a self-signed one that has the IP. Cons: All clients will complain about it and some will refuse to connect altogether.
OK, reading through that thread has been quite enlightening. Originally, when I setup NGINX I didn’t have a way to change A Name records. I’m running Nest WiFi (a patently terrible purchasing decision if I’ve ever made one) and there’s virtually no ability to customize on these routers. That said, I now have a Pi-Hole, and I just did some experimenting with a custom A-Name record… I see what you’re getting at, and I like it.
If I understand correctly, I should be able to turn off the NGINX plugin, re-enable the HTTPS stuff in config.yaml and be off to the races with some minor tweaking to port forwarding, etc. The biggest “issue” is that attempting to access “homeassistant.lan” will fail since that name isn’t on the certificate, so existing devices will have to be reconfigured to use the “external domain” but they’ll route back inwards… Clever. I think I like it, and it removes the NGINX add-on complexities.
Getting back to the original issue: I may be misunderstanding what I’m looking at, but it appears to me the NGINX proxy manager Add-On is capable of handing different certificates depending on the requested URL. As well as many other things that aren’t super relevant to me at the moment. Meaning, I could use this to hand a different (self-signed) certificate if I am accessing via Bare IP.
Am I understanding this correctly?
I’m going to do some more experimenting with this today.
You got it. I haven’t used that addon, but I’m sure that Nginx can expose a different certificate depending on the request URL. What I’d do is forward a port on the router to Nginx and use that connection only for requests to the IP. For all other connections use the external domain name.
If your router does not support port forwarding, then you have to keep using Nginx for all external connections.
The suggestion on the docs page is to use hosts. Trying that instead. Still get certificate mismatches, but the NGINX Proxy Manager Add-On does seem to help with that.
Shoot, didn’t know that. The hosts workaround would still require a domain name. I guess the only option left is to use a DNS provider allowed from your workplace.
Not sure what you mean? I put my external bare IP in and some “domain” that doesn’t really exist into the hosts file. The documentation’s example is “homeassistant.home”.
So now, when a DNS lookup happens for homeassistant.home it’s getting my home IP address. I generally worked from these directions so I could get rid of both the DuckDNS add-on (and replace it with the integration) as well as the NGINX SSL Add-On.
Then I added one more proxy-host, but for the Domain Names I entered “homeasistant.home”, for SSL I uploaded my self-signed certificate. Then I connected to my VPN and… ERR_TUNNEL_CONNECTION_FAILED
I think the corporate proxy is disbelieving me. I was so close…
Alright, this isn’t working. You might be right, if I want to fix this I probably need a different DNS provider.
Yeah, the corporate firewall is probably triggering on that .home TLD. And maybe it’s minting certificates on the fly too to be able to inspect SSL connections. Typical corporate man in the middle technique.
