The FQDN resolves fine. I can still reach Pihole over https://pihole.my.domain and click on “Proceed to pihole.my.domain (Risky)”, but the browser fetches Pihole’s self-signed certificate instead of my.domain and throws a warning about certificate validity. Which it absolutely shouldn’t, because Nginx conf for Pihole points to port 80, not port 443.
Comment on Pihole behind Nginx sudden certificate issue
folekaule@lemmy.world 1 day ago
Can you confirm that the DNS actually resolves to the NGINX IP address (and only that address) when you use PiHole’s FQDN? It sounds like it’s bypassing the proxy because it stopped working when you turned 443 off.
AbsolutelyClawless@piefed.social 1 day ago
AbsolutelyClawless@piefed.social 1 day ago
Hm, looks like you’re right. For some reason it’s completely bypassing Nginx. Traceroute to all my other proxied services points to nginx.my.domain, except pihole, which points to pihole.my.domain. There have been no changes to my configuration, this is odd.
folekaule@lemmy.world 1 day ago
What is your DNA setup like? A lot of dhcp clients are set up to register their name in DNS (if allowed). It could be your pihole server is hijacking it.
If you have multiple DNS servers (eg your home router and your lab) them you may not be getting the full picture.
AbsolutelyClawless@piefed.social 1 day ago
Pihole is my DNS server (Unbound + Local).
I fixed it? After the issue appeared I changed Raspi’s hostname to FQDN, i.e. pihole.my.domain. So it sort of makes sense that it bypassed Nginx. I changed it back to how it was before (just “pihole” and instead of my.domain I added “home.arpa” as local domain). And now it’s back to normal. Which makes about zero sense to me, because I basically just changed it back how it was both before and after the issue started.
Thanks for the help! It didn’t even occur to me to look if Nginx was being bypassed.
folekaule@lemmy.world 1 day ago
Glad you got it working!
My hypothesis is that it was DNS (channeling Jeff Geerling here). Since Pihole is your DNS (makes sense), it may have recognized that address as its own and given you its IP. By resolving the naming collision, you fixed the problem because the name is now unambiguous.
These problems can happen very easily when you’re using DHCP and sharing a network and domain name between your clients and upstreams, so I think using home.arpa for one and your other domain for the other was a good idea.