Question 91133 in Apache Question posted in
Some documentation to get you started can be found here.

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.

enter image description here

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.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    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

    enter image description here

    enter image description here

    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..


  2. 0

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search