Ausgabe
Beim Zugriff auf https://mcgillcrm.com sehen einige Benutzer dies in Chrome: ERR_SSL_PROTOCOLund das ist Firefox:SSL_ERROR_RX_RECORD_TOO_LONG
Dies geschieht jedoch nur, wenn sie über einen bestimmten ISP (Videotron) auf die Website zugreifen.
Wenn auf die Site über einen Hotspot zugegriffen wird oder wenn sie mit einem anderen ISP verbunden ist, funktioniert es einwandfrei und es funktioniert auch, wenn der Benutzer einen Windows-Computer anstelle eines Mac verwendet.
Ich habe SSL-Labs überprüft, Port 443 überprüft und mit einer anderen Website verglichen, auf der dieser Fehler nicht auftritt und alles in Ordnung zu sein scheint.
Wir haben eine 301-Weiterleitung zu https und ich habe doppelt überprüft, ob Benutzer wirklich https:// eingeben, wenn sie auf die Website zugreifen, aber es funktioniert immer noch nicht.
Wie erfolgt die Verbindung zum ISP im Vergleich zu einem anderen ISP oder Mobilfunknetz?
- Mac-Benutzer stellt eine Verbindung zum drahtlosen Modem her: SSL-Fehler werden angezeigt
- Mac-Benutzer stellt eine Verbindung zum drahtlosen mobilen Hotspot her: Es wird kein Fehler angezeigt
Aktualisierung 12. Oktober 2022
Wir haben ein neues Zertifikat von Grund auf neu installiert und dieses zeigt nirgendwo „selbst signiert“ an. Mal sehen ob es hilft.
Lösung
Es stellte sich heraus, dass das Problem bei safebrowse.io lag, das irgendwie das falsche Zertifikat zwischenspeicherte (das Löschen des SSL-Zertifikats in Chrome hat nicht geholfen).
Es betraf wiederum andere Browser wie Firefox. Sobald das falsche Zertifikat zwischengespeichert wurde, wurde es global als unsichere Site gekennzeichnet.
Es sieht so aus, als ob es im Chrome-Profil des angemeldeten Benutzers (Google Workspace-Konto) zwischengespeichert wurde.
Die Lösung bestand darin, sich als Gast anzumelden > zur Website zu gehen > auf “Trotzdem fortfahren” zu klicken > Chrome neu zu starten
Dies sieht nach einem schwerwiegenden Designfehler bei safebrowse.io aus, warum/wie SSL-Zertifikate im Chrome-Profil zwischengespeichert werden, ist unklar. Dies hätte beim Zugriff auf die Website in Chrome inkognito funktionieren sollen, aber es hat nicht funktioniert.
Beantwortet von – Robert Sinclair
Antwort geprüft von – Cary Denson (FixError Admin)
