When some customers visit my site of eztia.health , they get an error that says “this site cannot provide a secure connection” (screenshot attached). Not everyone gets this error—some can access it just fine. Why can some people not access the site?? When trying to get new customers and investments… this is highly concerning.
I have looked into the SSL certificate, contacted google about the domain, and even contacted Webflow and no one has been able to provide a solution. When I check the SSL on this site: SSL Certificate Checker , it does say that “Root 1” is missing, but it also says it was issued in 2000, long before this website existed. I do not know how to renew this and when I brought this up to Webflow, they said it shouldn’t be a problem anyway.
I have heard before it could be an issue with a virus protection on a computer… However, the CEO of the company just returned from a trip and all of a sudden couldn’t access it on her computer. When there have been no changes to her computer since last accessing the site.
I’ve tried updating browsers, clearing cache, disabling SSL (not ideal obviously) and nothing works. The site SHOULD be secure in every sense of the word. WHY DOES THIS HAPPEN?
Best guess is that the users having problems are operating from behind a proxy that is replacing your SSL with another. Fairly common for schools, and workplaces that want to monitor message content and browsing behaviors.
Thanks for the response @memetican and thanks for checking the cert. A couple things:
Assuming that a school/workplace would do this to the site, is there any way to combat it? We speak with a lot of schools, governments, and big businesses that would need to access the site with ease. If its a secure site, why would the monitoring block it?
Also, this problem occurred on the same laptop on the personal wifi of the CEO—and it happened all of a sudden. One day she could access the site fine. 2 weeks later (after a vacation), now she can’t access it. Nothing changed with her computer, wifi, or virus protection.
Although there doesn’t seem to be a problem, there is.
I can only guess, but it seems likely that she was switching between standard wifi and a corporate VPN network.
Is this the only client that has indicated problems? If so, I’m placing my bets on a proxy or VPN configuration issue on their network, or on her laptop specifically. The CEO should be seeing these types of intermittent failures on many sites, not just yours, but she might not know if she doesn’t do a lot of browsing on external sites.
If you have multiple unrelated clients who are getting this it’s something broader.
No great answers here, as all of this becomes politically sensitive. You can’t really say “your laptop is broken” or “can I talk to your IT department”, but you might be able to suggest the problem is at her end with “have you seen this problem on other sites you’re visiting? … Our research is indicating it might be a configuration problem with your VPN or a network router…”
I think the easiest and most sensible approach is to ask her to turn off her VPN to ensure it’s not interfering, but I’m making a lot of guesses here. She may not even know she’s using a VPN if she’s installed some browser plugin. That would actually tie into her vacation if she travelled internationally. People often install those plugins to fix geo-restrictions on their favorite sites.
You can’t really fix her problems at your end, but you might be able to detect the proxy weirdness using a reverse proxy setup on your own site, so that you can inspect the request, origin IP, useragent and possibly SSL information.
If you can detect when an external proxy is being used, you could display a message indicating that “this site is being accessed through a proxy, and may not function as designed…” These are muddy waters though, and even if you can find unique markers, they could change at any time.
It’s a bit of an ugly project. If I had to do it, I’d create a page specifically for that CEO, and setup a reverse proxy that watches and fully logs all requests to that page specifically. Then ask the CEO to access it and see if she has problems there. When she has problems, you’d then analyze the logs for any differences you can find in the requests, and then setup your alert messaging accordingly.
This is a fairly situationally-specific problem & solution though. You might be able to find a third-party proxy detection service you can buy that will provide something more general. They’d like have databases of IP’s, user-agent strings, etc. that are used in the detection.
@memetican Thank you so much for this in depth explanation. This is more information than I’ve gotten out of Webflow and Google combined. You mentioned that if its happening to multiple, unrelated clients then its something broader… It HAS happened to other people, on other wifi networks in other locations. That’s why I’m concerned its an internal problem.
There was at least one other instance of a customer not being able to visit the site, getting the same error. In this instance, we knew them personally and were able to troubleshoot that it was their virus protection software. We had them turn off their virus protection on their laptop—then they could access the site. But they could not access the site with virus protection on.
For the CEO, she turned off her wi-fi and was able to access the site with mobile data.
We have also gotten feedback from people in other countries that haven’t been able to access the site with the same error.
This is worrisome because obviously we won’t always be able to troubleshoot with customers. If they get this error—they will navigate away and probably never come back. Who knows how many other people this has happened to without our knowledge.
In short—this is a broader issue. Why would a virus protection software block the site in the first place if its entirely secure?
I’ve done some quick checks to see if I can find any blacklists containing Webflow’s IP’s. 188.8.131.52, 184.108.40.206 and proxy-ssl.webflow.com ( resolves to 220.127.116.11 ), are all showing as 100% clean on mx toolbox.
Anti-virus providers often maintain their own lists, but in most cases the message is different and you can track it down. I’m having difficulty tracking down the first screenshot you gave from “Advanced Security”, but it seems part of a device suite under the brand Xfinity. Maybe a wifi router?
If you can ID an error from another antivirus like Avira, Avast, Norton… those are a bit easier to track and contest as a false positive. A few have support teams you can reach as well to find out more.
But, my instincts are still telling me that VPN’s and proxies are a part of the issue here.
Here are the puzzle pieces driving that conclusion;
Most people access your site fine
There are zero red flags on any Webflow IP’s that I can find
Your client CTO is able to access it by switching off wifi. She’s not changing her antivirus settings, just her network route
Antivirus providers are increasingly using VPNs and proxies as part of their safe browsing infrastructure, because it lets them police every byte for malware sigs.
If the AV and VPN are separate systems, or if there are multiple AV systems interplaying ( one on the PC, a different one security the network ) things get more complex - the AV would often see the proxy’s IP addresses rather than Webflow’s.
We have no idea what those IP’s would be, so we can what it’s seeing, what’s happening regarding the SSL cert the proxy provides, and what IP’s might be blacklisted
Some people use VPN’s to browse porn, etc, which tend to be heavier targets for virus and malware distribution. That means a user hits a site with malware on a proxied VPN, and is running AV software, that AV would flag it, and associate the proxy’s IP. However that IP doesn’t represent that site- it’s part of the the VPN infrastructure. My guess is this leads to a lot of red flags and blacklisting on VPN proxy IP’s, which affect everyone else using that same VPN with that same AV suite.
All of that leads to a big gnarly mess regarding how users are accessing your site and what might interfere.
You could spend a lot of time trying to Sherlock this, but it would require a lot of client involvement, and even when you find the problem(s) there is no guarantee you can fix it.
I’d try reverse proxying the site first so that the IP’s and SSL cert change. That would basically make it a different site from the perspective of the network, AV databases, VPN proxies, etc- the only things staying constant are the domain and the content, which both appear fine.
I have something we can do as a test on this, I’ll drop you a message.