I switched to a UDM so I lost my HAProxy on my pfsense install. I was excited when I saw Tom released a video on something to fill the gap. I’m not having much luck with NPM doing a DNS challenge with my DNS hosted in cpanel though. Seems it’s using an old version of cpanel certbot plugin basted on this post - Cpanel setup · NginxProxyManager/nginx-proxy-manager · Discussion #3057 · GitHub. Hopefully the update submitted gets merged soon and it makes it into the docker image. I tried the suggested edit in my link but I’m still getting the same error.
Maybe it’s time to move DNS out of Cpanel to something else. I did manage to get this all working HAProxy though so it is possible with my host.
I tried following the video instructions but am having trouble, likely because I’m using pfSense as my gateway firewall. In DuckDNS, I’m using my WAN IP address and the SSL Certificate won’t authenticate. Also, I’m a little unclear how the DNS Resolver in pfSense cooperates with Nginx Proxy Manager in the resolution of local names.
No, I do not want any of these services to be public facing. I closed the ports, changed the IP address on DuckDNS to that of my server, and had to wait quite a while for the SSL Certificate to be authenticated.
I had to create a DNS override in pfSense to point the subdomain to my server running NPM for proxy hosts to work. Most hosts were fine such as Ubuntu, Proxmox, ESXi and OpenWRT.
The host in npm is configured properly (I have a wildcard SSL cert for my domain on the SSL tab), and if I choose to continue on the “Dangerous Site” message, everything works, but the whole point of having npm is to never get any kinds of alerts on the browser, especially not a red page like that…
Am I misconfiguring something either on npm or adguard home?
My adguard home runs just via http (no https) and there’s nothing special about it…
Is this site publicly accessible? If so, what is the exact URL structure? The part after ‘adguard-’ seems rather short for ‘adguard-something’ to be just a subdomain, or if it is a subdomain, then the domain name must be rather short. Therefore, the URL is probably something like ‘adguard-something.xyz.com’ or ‘adguard-home.xyz.com’. Especially the last one, would be exactly what scammers would use for a phishing site.
Also, what top-level domain are you using? Is it a free one, or one such as .xyz, which are often used by malicious actors?
Any of these factors, or of course if your site has actually been hacked and/or is distributing malware, could cause Google to classify your site as unsafe or malicious. This can happen through user reports or, more likely, through an automated process at Google.
In your case, I would guess that it is most likely a false positive, i.e. some AI bot at Google has incorrectly identified your site as malicious due to the URL you are using.
I do have a separate question: in Tom’s video he was suggesting that the configuration of each FQDN be done in the local DNS server. But was also wondering: is there any reason why that configuration could not or should not be done in the registrar for my domain?
I checked and the registrar allows me to create an A-Record that points adguard-01.my-last-name.net to the internal IP address of my npm server. Obviously this won’t work for anyone on the open internet who can’t reach that LAN IP, but it would work for all the devices on the LAN network (just instead of using the local DNS to resolve the FQDN, it would use the public DNS servers for that…)
I was able to solve the issue by turning off the “Block Common Exploits” option in the hosts configuration.