ERR_SSL_PROTOCOL and SSL_ERROR_RX_RECORD_TOO_LONG with a specific ISP only - apache

When accessing https://mcgillcrm.com some users are seeing this in chrome: ERR_SSL_PROTOCOL and this is firefox: SSL_ERROR_RX_RECORD_TOO_LONG
But it only happens when they access the site through a specific ISP (Videotron).
When the site is accessed via a hotspot or when connected to a different ISP it works fine and it also works if the user is using Windows machine instead of a Mac.
I verified SSL labs, checked port 443 and compared against another site where it doesn't throw this error and everything seems fine.
We have a 301 redirect towards https and I double checked that users really type https:// when accessing the web-site, but it still doesn't work.
How is the connection done to the ISP vs. how is the connection done to a different ISP or mobile network
Mac user connects to the wireless modem: SSL errors come up
Mac user connects to the wireless mobile hotspot: No error comes up
Update 12 Oct 2022
We re-installed a new certificate from scratch and this one is not showing 'self signed' anywhere. Will see if it helps.

HTTPS is end to end encryption and integrity protection. It should not depend on the ISP used by the client. If it is specific only to the ISP or specific clients then something is messed up at their end, like some middleboxes or antivirus interfering with the connection, a captive portal asking the client to acknowledge some rules first, DNS resolution pointing to a different IP then yours etc. There is nothing you can do from the server end against this, since maybe the server is not even reached by the client.

Problem turned out to be with safebrowse.io which was somehow caching the incorrect certificate (clearing SSL cert in chrome didn't help).
It in turn affected other browsers also like Firefox. So once the incorrect cert was cached it flagged it globally as an unsafe site..
It looks like it was cached inside the logged in users chrome profile (Google Workspace account).
Solution was to login as Guest > Go to web-site > Click 'Proceed anyway' > Restart Chrome
This looks like a serious design flaw with safebrowse.io, why/how it caches SSL certificates in Chrome profile is unclear. This should have worked while accessing the web-site in Chrome incognito but it didn't..

Related

SEC_ERROR_UNKNOWN_ISSUER (FireFox) / NET::ERR_CERT_AUTHORITY_INVALID (IE) at local Webserver

I am running a twiki installation on a Centos9 server that is accessible from our own network via http://twiki.
It is not accessible from outside.
I regularly get the warning SEC_ERROR_UNKNOWN_ISSUER (Firefox) or NET::ERR_CERT_AUTHORITY_INVALID (Internet Explorer, Edge). Of course I can ignore the warning, but after a while it pops up again and that's quite annoying for me.
What can I do to prevent this? I don't actually need https, http would suffice, but I always get redirected to the https version. Is this something the browser does? Or can I configure the web server (Apache) to prevent this?
To be honest, I'm not really a webmaster or network expert. I just need to get the Twiki working. What I've found out so far is that I'm getting the warning because I self-signed my SSL certificate and there is no known trusted author. I also can't get a signed SSL certificate because my server doesn't have a domain like .com or something.
If possible, I would prefer a solution on the server so that each user doesn't have to configure their browser

How can I access a self-signed webserver using SSL but from another computer on LAN?

Problem: Since Chrome updated a while back (version 58?), I'm not able to access my computer's development Express web server with HTTPS from a remote machine on the same private LAN.
I have created a self-signed certificate on the server (my laptop), and it works great from the same machine via https://localhost:8383 (the local SSL port).
In the past I could bypass the warning on a remote machine on the same network but it has stopped working.
I've gone through the steps of creating a local secure DNS server on my own router with DD-WRT, and self-signed a new certificate with SAN so I could use a DNS host name to access it without specifying an IP address.
I'm able to get to the page after bypassing the message that warns the site's SSL certificate could not be verified. But that's not good enough because while the site will load, the underlying websocket service I'm using on the same port does not work, and so the application loads but is broken on the remote machine. Still works on the local machine because the certificate is valid.
It seems the issue centers around Websockets within Express.
Any guidance would be greatly appreciated! This is a strictly secure environment that's meant to be used on a private network and it makes no sense for me to spend a bunch of money on a public certificate if that even matters.
Thank you.
It appears that the issue is with mobile Chrome and Safari on IOS -- I can get untrusted SSL certificates to work with websockets from another computer on the same network with the latest versions of Chrome and Safari. But on IOS (ipads and iphones), the page will load after being prompted, but Websockets FAIL to function whatsoever.
I've found a couple other people finding this issue.
My workaround for this problem was to revert away from SSL for my private network and completely avoid self-signed certificates.
In a private environment this is OK.

How to make browsers trust a local network wss:// connection?

I'm trying to upgrade a websocket connection ws:// to wss:// using a nginx reverse proxy https://github.com/nicokaiser/nginx-websocket-proxy/blob/master/simple-wss.conf
but I seem to be having trouble with the certificate part. My server is located on the same network as the client. So Ideally I would want my users to log in to "https://example.com" and then the client makes a connection to "wss://192.168.1.xxx:xxxx".
As of now the browsers are blocking it because of NET::ERR_CERT_COMMON_NAME_INVALID. I don't really know to produce a self signed certificate that the browsers will trust on the local network. Googling only gives me answers on how to do it if my server would be accessed using a domain name but I will always connect to a local network IP. Help is appreciated!
To anyone coming across this I managed to solve it using this post outlining the architecture https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
What ended up happening was that we set up a url pointing to a server running nginx which parsed the subdomain and redirected the connection to that url. For example: wss://192-168-1-142.mydomain.com redirects to ws://192.168.1.142 which makes the browser trust the connection
Does this work?
Your post is a year old now and browsers have become stricter since then. Usually, a browser will produce 'mixed content' errors if you access HTTP content from a HTTPS page, and the only way to get round this is to change the site settings to allow insecure content, which is scary for users in the face of a big warning message.
If accessing an HTTPS web address redirects to an HTTP local IP address, won't the browser still complain about mixed content?
I have a similar situation to you. I am writing a Progressive Web Application (PWA) to control network music players on a home network. The players only support HTTP but a PWA requires HTTPS for services workers to work and to allow the app to be 'installed'.
My solution is to run a local server on the home network which can talk to the players over HTTP. Then I can access this server over HTTPS from my browser so that the browser itself is not making any HTTP calls.
This works fine if the server is on localhost because localhost is a special case where security rules are relaxed. But if the server is on another machine, how can I create an SSL certificate since (1) it seems that local IP addresses are not allowed in the Subject Alternative Name (SAN) section of the certificate, and (2) I won't know in advance what the IP address of the server will be.
If your workaround works, then the local server can use HTTP instead so I won't need a certificate. The local server can register itself with a web server, and then the browser can connect over HTTPS to the web server, which would redirect to the IP address of the local server over HTTP.
But does this trick work?

DNS rerouting SSL issue

I have a blocklist for my internal network that reroutes the user to another IP address should there be a match. This is managed via SimpleDNS and a tool within that program. The rerouting works and it goes to the IP address.
Code on the IP website then logs the hit and reroutes to a fully qualified domain and shows the user a message.
Except I now have an issue inbetween SimpleDNS rerouting to the IP and the friendly page being showen
Your connection is not private
Attackers might be trying to steal your information from www.starbucks.co.uk (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
Automatically send some system information and page content to Google to help detect dangerous apps and sites. Privacy policy
(starbucks.co.uk is just a test site in the blocklist)
I can then click on the Advanced > Proceed and it goes to the correct location but is there anyway I can bypass that. I'm guessing it's an ssl issue somewhere somehow.
Setup is Windows Server 2016 running IIS. I have an SSL on the end domain which is installed and works correctly.
Thanks
Paul

Charles Error Report: How to over come it?

I have recently switched from mac development environment to windows development environment. I was used Chrles proxy extensively to capture network traffic, requests and response details. Right now I have installed Charles proxy version 3.7 in windows 8. How ever I have observed that the website on which I am working is not opening at all with Charles proxy ON. It is showing below exception message. And it is working perfectly for all other websites.
Charles Error Report
Failed to connect to remote host
Charles failed to connect to the remote host. Check that your Internet
connection is ok and that the remote host is accessible. Maybe your
network uses a proxy server to access the Internet? You can configure
Charles to use an external proxy server in the External Proxy
Settings.
The actual exception reported was:
java.net.ConnectException: Connection timed out: connect Charles
Proxy, http://www.charlesproxy.com/
Research that I have done before coming to SE:
I have searched in google with the keyword "Charles Error Report-Failed to connect to remote host". I got couple of links which are related to the above issue.
First link says to check for external proxy setting. I have checked, there are no external proxy settings in my computer.
Second link says open the url in browser and close charles proxy and reopen it. I did that. Still no luck.
How to overcome this issue?
Do you get the same problem with other proxies like Fiddler? If so, it's probably not related to Charles but either a network problem or inability of your application to work with a proxy.
Other causes may be using HTTPS (which can cause certificate errors) or using the loopback address (localhost or 127.0.0.1) which may or may not be ignored by the proxy.
UPDATE
In IE10+ Enhanced Protection Mode prevents untrusted applications from accessing local resources. Pages and sites that are not in the Trusted Zone are considered unstrusted, so they can't connect to any local proxy. Fiddler includes a configuration button to configure Windows 8 to bypass this. You can find a very good explanation of what happens and why here.
In Windows 8, EPM is enabled only for Metro IE. In 8.1 it is enabled by default even for Desktop IE.
You may be able to make Charles work again simply by adding your site's address to the Trusted Zone in IE's security settings, or you can download the EnableLoopBackUtility mentioned in Configure Fiddler for Windows 8 Metro-style applications to allow IE to connect to your site through the local proxy
I have experienced this as a timing or caching related gremlin. For me, in most cases, this is resolved by doing force-reload a few times in the browser. Doing so is slightly different on each platform. In Mac/Chrome, holding down Command + Shift + R for a couple of seconds does the trick. In Win/IE, holding Shift and clicking the reload icon in the address bar a couple of times does it - in theory, Shift + F5 should do the same thing, but it does not work as well.