Welcome to the InfinityFree community forum! Good to have you here.
Most people answering here are volunteers. They’re often the fastest source of help. Admin (the only staff member) checks in about once a day for issues on our end.
Volunteers can’t see your account or website. Share what you actually see, like error messages and what happens when you try something. That’s more useful than your theory of what’s wrong.
AI tools often get InfinityFree wrong. If a volunteer’s advice differs from what an AI told you, please try the volunteer’s suggestion first.
Solving an issue is a joint effort. Try the suggestions you get and report back what happened.
Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look.
Can you run nslookup rybariledec.great-site.net on a device that’s on the failing Wi-Fi, without the Google Private DNS setting, and tell me which IP address it returns? If you can, also open the certificate warning and tell me which name and issuer the certificate shows. And is it one Wi-Fi network or several different ones?
I’m asking because DNSChecker only shows what public resolvers around the world say. It doesn’t show what the resolver on that Wi-Fi says. Your site works on mobile data and works on the same Wi-Fi once you switch to dns.google. So the Wi-Fi’s own DNS resolver may be returning a different address, or something on that network may be intercepting the connection. A certificate for a different name and a login prompt your site doesn’t normally show would fit that. If the lookup on the Wi-Fi returns something other than 185.27.134.141, that’s the cause, and it would be on the network’s side rather than your hosting.
I couldn’t find any forum topic or article that explains this. The two topics with the same certificate error that I found had no answer for it.
I would like to clarify one important thing: this issue occurs on several different Wi-Fi networks, not just my home Wi-Fi.
Multiple visitors have reported that they cannot access my website when connected to Wi-Fi.
The website works correctly on mobile data. I also confirmed that changing the Private DNS setting to dns.google makes the website work on a previously affected Wi-Fi network.
Without that change, visitors may receive:
NET::ERR_CERT_COMMON_NAME_INVALID
401 Unauthorized
An unexpected username and password prompt
Public DNS checks consistently show 185.27.134.141.
Since this happens on multiple Wi-Fi networks, could you please investigate whether there is a wider DNS resolution, filtering, or routing issue affecting the great-site.net subdomain?
I understand that a DNS lookup directly from an affected Wi-Fi network is needed to identify the cause. I will try to provide that result.
I would appreciate your help identifying a permanent solution so visitors can access the website without changing their DNS settings.
I checked your website, and it is working perfectly for me. It’s using the standard SSL certificate for *.great-site.net from ZeroSSL and returning a normal web page, not a credential prompt.
The combination of the ERR_CERT_COMMON_NAME_INVALID error along with the unexpected response points to one clear explanation for me: someone or something is hijacking the connection between you and your website, and routing it to a destination they control. That alternative destination is generating the credential prompt, and since it does not have a valid SSL certificate for your website, you get the ERR_CERT_COMMON_NAME_INVALID error.
The fact that changing the DNS resolver works to bypass this already answers the “how”, but does not answer the “who” or “why”.
You say you already checked the domain with a public DNS check, which returns the correct IP address. But can you also check what the domain points to from your computer without using Google’s DNS? That might give us a clue.
Another clue would be the SSL certificate that is actually presented to your browser. It is clearly not the one from our server. Can you view the certificate details and view the actual subject of the certificate and the issuer? That might also give us a clue as to where the certificate came from.
The behavior you are seeing is usually caused by a network filter, probably one that is blocking the great-site.net domain.
