23
Sporadischer Internetausfall err ssl protocol error
Guten Tag,
ich nehme neuerdings einige Administrative Aufgaben in einem kleinen Unternehmen mit 30 Arbeitsplätzen wahr.
Wir haben neuerdings ein sporadisch auftretendes, sehr nerviges Problem und hoffen auf einen Lösungsweg.
Dies tritt beim Aufruf von SSL Websites wie z.B. google.de bei einigen Mitarbeitern, nicht allen, sporadisch auf und verschwindet wieder.
Es kommt dann je nach Browser die Fehlermeldung "err_ssl_protocol_error" oder "SSL_ERROR_RX_RECORD_TOO_LONG"
Wenn der Fehler gerade da ist und ich die IP von google eingebe, komme ich auf die Seite von google. Deshalb denke ich, dass das Problem mit DNS zu tun hat.
Der aktuelle DNS Eintrag ist der Server mit dem Active Directory
Den Eintrag auf 8.8.8.8 zu switchen hatte allerdings nich geholfen
Zur Infrastruktur:
Windows 10 Arbeitsplatz, Lancom Rohde & Schwarz Firewall (LCOS FX 10.12.6271RU2)
Ich hoffe mir kann jemand helfen.
ich nehme neuerdings einige Administrative Aufgaben in einem kleinen Unternehmen mit 30 Arbeitsplätzen wahr.
Wir haben neuerdings ein sporadisch auftretendes, sehr nerviges Problem und hoffen auf einen Lösungsweg.
Dies tritt beim Aufruf von SSL Websites wie z.B. google.de bei einigen Mitarbeitern, nicht allen, sporadisch auf und verschwindet wieder.
Es kommt dann je nach Browser die Fehlermeldung "err_ssl_protocol_error" oder "SSL_ERROR_RX_RECORD_TOO_LONG"
Wenn der Fehler gerade da ist und ich die IP von google eingebe, komme ich auf die Seite von google. Deshalb denke ich, dass das Problem mit DNS zu tun hat.
Der aktuelle DNS Eintrag ist der Server mit dem Active Directory
Den Eintrag auf 8.8.8.8 zu switchen hatte allerdings nich geholfen
Zur Infrastruktur:
Windows 10 Arbeitsplatz, Lancom Rohde & Schwarz Firewall (LCOS FX 10.12.6271RU2)
Ich hoffe mir kann jemand helfen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 33058177851
Url: https://administrator.de/contentid/33058177851
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
23 Kommentare
Neuester Kommentar
Tag.
stimmt denn die Uhrzeit am Client sowie Server? Diese sollte ziemlich genau sein (maximal 5 Minuten differenz). Bist Du über den 5 Minuten, bist Du kein Teilnehmer mehr des Netzwerkes (Internet).
Prüfe das.
Gruß
stimmt denn die Uhrzeit am Client sowie Server? Diese sollte ziemlich genau sein (maximal 5 Minuten differenz). Bist Du über den 5 Minuten, bist Du kein Teilnehmer mehr des Netzwerkes (Internet).
Prüfe das.
Gruß
Ist in der Firewall eine Art Webproxy oder Webfilter aktiv?
1
Moin,
Google ist Dein Freund. Ein einfaches kopieren der Meldung in die Suche hilft ungemein.
Mit DNS hat das nicht im Geringsten was zu tun.
Im AD darf der DNS-Server kein Server außerhalb der Domain sein. Die Domain steht und fällt mit der korrekten Konfiguration des DNS.
Hier zwei Artikel, was die Meldungen bedeuten und was Du evtl. tun kannst.
https://www.hostinger.com/tutorials/err_ssl_protocol_error
https://www.thesslstore.com/blog/ssl_error_rx_record_too_long/
hth
Erik
Zitat von @ChristianV8:
ich nehme neuerdings einige Administrative Aufgaben in einem kleinen Unternehmen mit 30 Arbeitsplätzen wahr.
Wir haben neuerdings ein sporadisch auftretendes, sehr nerviges Problem und hoffen auf einen Lösungsweg.
ich nehme neuerdings einige Administrative Aufgaben in einem kleinen Unternehmen mit 30 Arbeitsplätzen wahr.
Wir haben neuerdings ein sporadisch auftretendes, sehr nerviges Problem und hoffen auf einen Lösungsweg.
Google ist Dein Freund. Ein einfaches kopieren der Meldung in die Suche hilft ungemein.
Dies tritt beim Aufruf von SSL Websites wie z.B. google.de bei einigen Mitarbeitern, nicht allen, sporadisch auf und verschwindet wieder.
Es kommt dann je nach Browser die Fehlermeldung "err_ssl_protocol_error" oder "SSL_ERROR_RX_RECORD_TOO_LONG"
Wenn der Fehler gerade da ist und ich die IP von google eingebe, komme ich auf die Seite von google. Deshalb denke ich, dass das Problem mit DNS zu tun hat.
Es kommt dann je nach Browser die Fehlermeldung "err_ssl_protocol_error" oder "SSL_ERROR_RX_RECORD_TOO_LONG"
Wenn der Fehler gerade da ist und ich die IP von google eingebe, komme ich auf die Seite von google. Deshalb denke ich, dass das Problem mit DNS zu tun hat.
Mit DNS hat das nicht im Geringsten was zu tun.
Der aktuelle DNS Eintrag ist der Server mit dem Active Directory
Den Eintrag auf 8.8.8.8 zu switchen hatte allerdings nich geholfen
Den Eintrag auf 8.8.8.8 zu switchen hatte allerdings nich geholfen
Im AD darf der DNS-Server kein Server außerhalb der Domain sein. Die Domain steht und fällt mit der korrekten Konfiguration des DNS.
Ich hoffe mir kann jemand helfen.
Hier zwei Artikel, was die Meldungen bedeuten und was Du evtl. tun kannst.
https://www.hostinger.com/tutorials/err_ssl_protocol_error
https://www.thesslstore.com/blog/ssl_error_rx_record_too_long/
hth
Erik
1
Moin,
So richtig das für das AD ist, so falsch ist es beim Zugriff auf das Internet, da hier der Zugriff nicht auf Kerberos basiert.
Liebe Grüße
Erik
Zitat von @8585040390:
stimmt denn die Uhrzeit am Client sowie Server? Diese sollte ziemlich genau sein (maximal 5 Minuten differenz). Bist Du über den 5 Minuten, bist Du kein Teilnehmer mehr des Netzwerkes (Internet).
stimmt denn die Uhrzeit am Client sowie Server? Diese sollte ziemlich genau sein (maximal 5 Minuten differenz). Bist Du über den 5 Minuten, bist Du kein Teilnehmer mehr des Netzwerkes (Internet).
So richtig das für das AD ist, so falsch ist es beim Zugriff auf das Internet, da hier der Zugriff nicht auf Kerberos basiert.
Liebe Grüße
Erik
so falsch ist es beim Zugriff auf das Internet
Sämtliche Zertifikate werden ungültig, wenn die Zeit am lokalen PC nicht passt zu der restlichen Zeit des Netzwerkes.LG
Zitat von @8585040390:
LG
so falsch ist es beim Zugriff auf das Internet
Sämtliche Zertifikate werden ungültig, wenn die Zeit am lokalen PC nicht passt zu der restlichen Zeit des Netzwerkes.LG
Das ist bei SSL schlicht und ergreifend falsch. Mehr ist dazu nicht zu sagen.
1
Oh je, gleich wieder eine Debatte...
Dabei ist beim aktuellen Sachstand nahe liegend doch eine nicht ausreichend gewartete SSL-Interception, wahrscheinlich auf der Firewall. Kollege @lucas1243 spricht es oben schon an.
Viele Grüße, commodity
Dabei ist beim aktuellen Sachstand nahe liegend doch eine nicht ausreichend gewartete SSL-Interception, wahrscheinlich auf der Firewall. Kollege @lucas1243 spricht es oben schon an.
Viele Grüße, commodity
1Zitat von @8585040390:
LG
so falsch ist es beim Zugriff auf das Internet
Sämtliche Zertifikate werden ungültig, wenn die Zeit am lokalen PC nicht passt zu der restlichen Zeit des Netzwerkes.LG
Nein. Dein Client schaut einfach nach ob das Zertifikat gültig ist.
Solange deine lokale Zeit innerhalb des Zeitfensters des Zertifikates liegt (Zeitpunkt der Erstellung, Zeitpunkt des Ablaufes) ist das Zertifikat zeitlich gültig.
Ich füge hinzu, dass das auch ein lokaler Virenscanner verursachen kann, wenn er TLS aufbricht.
2
Ich versuche alle bisher genannten Aspekte zu beantworten
Wichtig ist nochmal zu erwähnen, dass nach ein Paar Minuten der Fehler teilweise weg ist, alles normal geht und ein Paar Minuten später wieder nicht! Deshalb frage ich mich ob es wirklch an einer falschen Konfiguration liegen kann. Dann würde es ja durchgehend nicht laufen oder sehe ich das falsch?
Uhrzeit: Die ist überall gleich und korrekt. Verglichen auf mehreren Clienten + Actice Directory Server
Firewall Webproxy Webfilter: Bei HTTP-Proxy: ist Klartext-HTTP-Proxy Transparent und HTTPS-Proxy Transparent. Bei Proxy-CA ist HTTPS-Proxy CA das angegebene Zertifikat.
Wichtig ist nochmal zu erwähnen, dass nach ein Paar Minuten der Fehler teilweise weg ist, alles normal geht und ein Paar Minuten später wieder nicht! Deshalb frage ich mich ob es wirklch an einer falschen Konfiguration liegen kann. Dann würde es ja durchgehend nicht laufen oder sehe ich das falsch?
Uhrzeit: Die ist überall gleich und korrekt. Verglichen auf mehreren Clienten + Actice Directory Server
Firewall Webproxy Webfilter: Bei HTTP-Proxy: ist Klartext-HTTP-Proxy Transparent und HTTPS-Proxy Transparent. Bei Proxy-CA ist HTTPS-Proxy CA das angegebene Zertifikat.
Zitat von @commodity:
Oh je, gleich wieder eine Debatte...
Dabei ist beim aktuellen Sachstand nahe liegend doch eine nicht ausreichend gewartete SSL-Interception, wahrscheinlich auf der Firewall. Kollege @lucas1243 spricht es oben schon an.
Viele Grüße, commodity
Oh je, gleich wieder eine Debatte...
Dabei ist beim aktuellen Sachstand nahe liegend doch eine nicht ausreichend gewartete SSL-Interception, wahrscheinlich auf der Firewall. Kollege @lucas1243 spricht es oben schon an.
Viele Grüße, commodity
Danke, in die Richtung könnte es auch gehen. Erklärt das aber, das google funktioniert, wenn ich die IP Adresse manuell eingebe?
Bzgl. der Zertifikate. Davon habe ich leider garkeine Ahnung. Im Anhang mal ein Ausschnitt aus der Firewall. Kann es an den dort abgelaufenen Zertifikaten liegen? Aber wäre das Problem dann nicht auch durchgehend?
Der lokale Virenscanner ist ESET Security und auch auf den Systemen die fehlerfrei laufen installiert. Selbst wenn ich dort im Netzwerkbereich alles für 10 Minuten deaktiviere funktioniert es leider nicht
Zitat von @ChristianV8:
Firewall Webproxy Webfilter: Bei HTTP-Proxy: ist Klartext-HTTP-Proxy Transparent und HTTPS-Proxy Transparent. Bei Proxy-CA ist HTTPS-Proxy CA das angegebene Zertifikat.
Firewall Webproxy Webfilter: Bei HTTP-Proxy: ist Klartext-HTTP-Proxy Transparent und HTTPS-Proxy Transparent. Bei Proxy-CA ist HTTPS-Proxy CA das angegebene Zertifikat.
Dann würde ich dort nach dem Fehler suchen.
Hallo,
cya
Firewall Webproxy Webfilter: Bei HTTP-Proxy: ist Klartext-HTTP-Proxy Transparent und HTTPS-Proxy Transparent. Bei Proxy-CA ist HTTPS-Proxy CA das angegebene Zertifikat.
und irgendwo da liegt der Hase im Pfeffer.cya
Ups,
zu langsam ;)
zu langsam ;)
Aus dem LCOS FX Manual:
---
Der HTTP(S)-Proxy dient als Mittelsmann. Er stellt eine Verbindung zum Webserver her, generiert mithilfe seiner eigenen
HTTP(S)-Proxy-CA ein Pseudo-Zertifikat für die Website und verwendet dieses, um eine Verbindung zum Browser
herzustellen. So kann der Proxy den Datenverkehr analysieren, URL- und Contentfilter anwenden und nach Viren suchen.
---
Da werden also Zertifikate "manipuliert".
---
Der HTTP(S)-Proxy dient als Mittelsmann. Er stellt eine Verbindung zum Webserver her, generiert mithilfe seiner eigenen
HTTP(S)-Proxy-CA ein Pseudo-Zertifikat für die Website und verwendet dieses, um eine Verbindung zum Browser
herzustellen. So kann der Proxy den Datenverkehr analysieren, URL- und Contentfilter anwenden und nach Viren suchen.
---
Da werden also Zertifikate "manipuliert".
Ich hatte soeben den HTTPS Proxy in der Firewall deaktiviert.
Die Clienten die nie fehler hatten, liefen weiterhin.
Die fehlerbehafteten Clienten hatten einen Wechsel der Fehlermeldung auf "NET::ERR_CERT_AUTHORITY_INVALID
Sagt das jemanden etwas?
Die Clienten die nie fehler hatten, liefen weiterhin.
Die fehlerbehafteten Clienten hatten einen Wechsel der Fehlermeldung auf "NET::ERR_CERT_AUTHORITY_INVALID
Sagt das jemanden etwas?
Hallo,
und auf welches Zertifikat wird da verwiesen?
cya
und auf welches Zertifikat wird da verwiesen?
cya
Zitat von @ChristianV8:
Ich hatte soeben den HTTPS Proxy in der Firewall deaktiviert.
Die Clienten die nie fehler hatten, liefen weiterhin.
Die fehlerbehafteten Clienten hatten einen Wechsel der Fehlermeldung auf "NET::ERR_CERT_AUTHORITY_INVALID
Sagt das jemanden etwas?
Ich hatte soeben den HTTPS Proxy in der Firewall deaktiviert.
Die Clienten die nie fehler hatten, liefen weiterhin.
Die fehlerbehafteten Clienten hatten einen Wechsel der Fehlermeldung auf "NET::ERR_CERT_AUTHORITY_INVALID
Sagt das jemanden etwas?
weil du nur den Dienst deaktiviert hast.
Da wird vermutlich eine Portweiterleitung in der Firewall sein, welche Port 80/443 umleitet. Mehr kann ich dazu aber auch nicht sagen, da ich mit der Firewall nicht arbeite.
In der Firewall bei eingeschalteten HTTPS Proxy ist das Zertifikat "HTTPS PROXY CA" dieses ist aber laut Liste in der Firewall aktuell noch gültig.
Bei ausgeschalteten HTTPS Proxy steht zu der Fehlermeldung "NET::ERR_CERT_AUTHORITY_INVALID" kein weiteres Detail. Wenn ich auf Erweitert klickt kommt "www.google.de schützt ihre Daten mithilfe von Verschlüsselung. Als Microsoft Edge dieses Mal versuchte, eine Verbindung zu www.google.de herzustellen, hat die Webite ungewöhnliche oder falsche Anmelddaten zurückgesendet.....
...
Sie können www.google.de im Moment nicht besuchen, da die Website HSTS verwendet.
Moin,
an der Stelle solltest Du einen Dienstleister zu Rate ziehen, der sich mit der FW auskennt. Es liegt mit ziemlicher Sicherheit an eine fehlerhaften Konfiguration an der Stelle.
Liebe Grüße
Erik
an der Stelle solltest Du einen Dienstleister zu Rate ziehen, der sich mit der FW auskennt. Es liegt mit ziemlicher Sicherheit an eine fehlerhaften Konfiguration an der Stelle.
Liebe Grüße
Erik
Wenn du keine Ahnung von SSL und Zertifikaten hast, dann wird das hier leider ein wildes rumgerate.
Der LACOS Proxy bricht die Ende-zu-Ende Verschlüsselung auf (z.B. zu Google).
Dann bekommen die Clients nicht das Zertifikat von Google zu sehen, sondern das Pseudo Zertifikat aus dem Proxy.
Aus Sicherheitsgründen merken sich die Browser, welches Zertifikat eine Seite gerade noch hatte(Certificate Pinning). Wenn sich das dann "plötzlich" ändert (z.B. weil der Proxy ein/ausgeschaltet) wird, verweigern sie den Zugriff. Das ist aber zum Teil anhängig vom Browser (die du uns verschwiegen hast) und teilweise auch vom Betriebssystem (welches wir auch nicht kennen).
Gibt es nicht auch im DNS Einträge der Seriennummer des Zertifikats einer Seite, damit man genau so ein "Man-in-the-Middle" verhindern kann?
Wie wird der LACOS Proxy auf dem Clients konfiguriert?
Müssen LACOS CAs auf den Clients installliert werden?
Der LACOS Proxy bricht die Ende-zu-Ende Verschlüsselung auf (z.B. zu Google).
Dann bekommen die Clients nicht das Zertifikat von Google zu sehen, sondern das Pseudo Zertifikat aus dem Proxy.
Aus Sicherheitsgründen merken sich die Browser, welches Zertifikat eine Seite gerade noch hatte(Certificate Pinning). Wenn sich das dann "plötzlich" ändert (z.B. weil der Proxy ein/ausgeschaltet) wird, verweigern sie den Zugriff. Das ist aber zum Teil anhängig vom Browser (die du uns verschwiegen hast) und teilweise auch vom Betriebssystem (welches wir auch nicht kennen).
Gibt es nicht auch im DNS Einträge der Seriennummer des Zertifikats einer Seite, damit man genau so ein "Man-in-the-Middle" verhindern kann?
Wie wird der LACOS Proxy auf dem Clients konfiguriert?
Müssen LACOS CAs auf den Clients installliert werden?
an der Stelle solltest Du einen Dienstleister zu Rate ziehen
Oder mal das Handbuch lesen 
Entweder leiten hier die Clients selbst auf den WebProxy der Firewall oder die Firewall leitet die Anfragen um (wahrscheinlicher). Wenn Du also den Service abschaltest, kann da nichts sinnvolles rauskommen. Du musst entweder das Problem lösen (ich tippe auf "Default AppFilter Certificate") oder die Umleitung rausnehmen.
Wenn Du die IT der Firma machen willst, musst Du Netzwerk und Firewall beherrschen. Wenn nicht: Rat des Kollegen @erikro beherzigen.
Generell kann ich Dir nur davon abraten, Dir als (wahrscheinlich IT-)interessiertem Mitarbeiter die Technik aufdrücken zu lassen. Nebenbei und ohne Qualifikation kannst Du es nicht richtig machen und in der Zeit, die Du dabei vertrödelst, Dinge zu lösen oder Quali zu erwerben, ziehen Deine Kollegen fachlich an Dir vorbei. Du bleibst dann zwar gefragt, aber trotzdem nur der Computerfuzzi. Nicht Fisch, nicht Fleisch (sagt nicht nur der Veganer
) Rate mal, wer später den Aufstieg macht...Das gilt natürlich nur allgemein. Es mag besondere Fälle und Begabungen geben...
Wenn Dich hingegen die IT mehr interessiert, als Deine eigentliche Qualifikation, mach es nicht wie ich und wechsele erst nach >20 Jahren...) mach zügig den Quereinstieg. IT'ler werden gebraucht. Immer mehr.
Viele Grüße, commodity
Es lag tatsächlich am Zertifikat. Ich musste das nur verteilen
