2
Automatische Aktualisierung der Stammzertifikate umgeht tlw. Proxy
Hallo,
diese Frage richtet sich an alle, die selbst einen Proxy im Einsatz haben
Umgebung:
- MS Server 2019. Proxyeinstellungen werden per GPO verteilt. So wird z.b. ein Regkey verteilt mit Einstellungen, die netsh winhttp set auch setzen würde. Direkter Internetzugriff ist über eine Firewall für den Rechner komplett gesperrt.
- auch wenn es glaub ich keine Rolle spielt: Linux Maschine mit Tinyproxy. Proxy wird nur als "Webfilter" verwendet.
Mein Problem:
Proxyeinstellungen werden erfolgreich an die Clients verteilt. Kann ich mittels netsh winhttp show proxy üperprüfen.
Im Log vom Proxy sehe ich auch, dass der Rechner diesen Proxy brav nutzt und z.b. ctldl.windowsupdate.com kontaktiert usw usw.
Doch nur ein paar Minuten später nach diesen erfolgreichen Zugriff sehe ich im Log der Firewall, wie der gleiche Rechner versucht, ctldl.windowsupdate.com direkt (ohne Proxy) zu kontaktieren, was aber natürlich geblockt wird. ctldl.windowsupdate.com ist hier nur ein Beispiel. Auch andere Zugriffe wie z.b. auf crt.sectigo.com sind zu sehen.
Im Log vom Proxy ist zu diesem Zeitpunkt nichts. Auch keine fehlgeschlagene Anfrage.
Also kurzum: manchmal nimmt er den Proxy, manchmal nicht. Wie der Server halt gerade Lust und Laune hat.
Meine Frage:
ist das bei euch auch so? Konntet ihr dieses Verhalten auch feststellen?
Wenn ja: habt ihr eine Lösung gefunden?
Oder muss ich mich damit einfach abfinden?
Gleich vorweg:
Warum nutze ich nicht ein PAC-File? Weil leider viele Programme diese Einstellungen nicht übernehmen. Und bis auf die Stammzertifikate läuft eigentlich alles vernünftig.
Beste Grüße
Patrick
diese Frage richtet sich an alle, die selbst einen Proxy im Einsatz haben
Umgebung:
- MS Server 2019. Proxyeinstellungen werden per GPO verteilt. So wird z.b. ein Regkey verteilt mit Einstellungen, die netsh winhttp set auch setzen würde. Direkter Internetzugriff ist über eine Firewall für den Rechner komplett gesperrt.
- auch wenn es glaub ich keine Rolle spielt: Linux Maschine mit Tinyproxy. Proxy wird nur als "Webfilter" verwendet.
Mein Problem:
Proxyeinstellungen werden erfolgreich an die Clients verteilt. Kann ich mittels netsh winhttp show proxy üperprüfen.
Im Log vom Proxy sehe ich auch, dass der Rechner diesen Proxy brav nutzt und z.b. ctldl.windowsupdate.com kontaktiert usw usw.
Doch nur ein paar Minuten später nach diesen erfolgreichen Zugriff sehe ich im Log der Firewall, wie der gleiche Rechner versucht, ctldl.windowsupdate.com direkt (ohne Proxy) zu kontaktieren, was aber natürlich geblockt wird. ctldl.windowsupdate.com ist hier nur ein Beispiel. Auch andere Zugriffe wie z.b. auf crt.sectigo.com sind zu sehen.
Im Log vom Proxy ist zu diesem Zeitpunkt nichts. Auch keine fehlgeschlagene Anfrage.
Also kurzum: manchmal nimmt er den Proxy, manchmal nicht. Wie der Server halt gerade Lust und Laune hat.
Meine Frage:
ist das bei euch auch so? Konntet ihr dieses Verhalten auch feststellen?
Wenn ja: habt ihr eine Lösung gefunden?
Oder muss ich mich damit einfach abfinden?
Gleich vorweg:
Warum nutze ich nicht ein PAC-File? Weil leider viele Programme diese Einstellungen nicht übernehmen. Und bis auf die Stammzertifikate läuft eigentlich alles vernünftig.
Beste Grüße
Patrick
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: 43046355110
Url: https://administrator.de/forum/automatische-aktualisierung-der-stammzertifikate-umgeht-tlw-proxy-43046355110.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
2 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
ist das bei euch auch so? Konntet ihr dieses Verhalten auch feststellen?
hast du das Debugging (Link) aktiviert und einmal angesehen was (nicht) geschieht?!Proxyeinstellungen werden erfolgreich an die Clients verteilt.
Welches OS?Gruß,
Dani
Meine Antwort hat nun etwas gedauert. Aber gut Ding braucht Weile
Danke für deine Tipps @Dani. Aber diese Seite ist schon ziemlich veraltet. Das set tracing funktioniert so nicht mehr. Der "neue" Befehl lautet netsh trace start scenario=InternetClient. Das erzeugt eine .etl Datei, die man nun im WPA (Windows Performance Analyzer) öffnen könnte.
Hab mich aber stattdessen für ProcMon entschieden, denn ich nun auf Path mit value :http lauschen lasse (da die Zugriffe auf die CTL-Listen immer über Port 80 raus wollten).
Aber: jetzt auf einmal gibts keine Verbindungsversuche mehr. Und ehrlich gesagt hab ich keine Ahnung warum.
Ich habe immer wieder ein paar Sachen geändert. Aber was genau den Fehler nun behob, kann ich nicht sagen.
Ich vermute, es war "Um den „winhttp“ Proxy für x86 Programme zu setzen ist die CMD aus dem Verzeichnis „C:WINDOWSsyswow64“ auszuführen" (Link). Hier hatte ich nämlich scheinbar nur winttp für x64 geändert.
Grüße
Patrick
Danke für deine Tipps @Dani. Aber diese Seite ist schon ziemlich veraltet. Das set tracing funktioniert so nicht mehr. Der "neue" Befehl lautet netsh trace start scenario=InternetClient. Das erzeugt eine .etl Datei, die man nun im WPA (Windows Performance Analyzer) öffnen könnte.
Hab mich aber stattdessen für ProcMon entschieden, denn ich nun auf Path mit value :http lauschen lasse (da die Zugriffe auf die CTL-Listen immer über Port 80 raus wollten).
Aber: jetzt auf einmal gibts keine Verbindungsversuche mehr. Und ehrlich gesagt hab ich keine Ahnung warum.
Ich habe immer wieder ein paar Sachen geändert. Aber was genau den Fehler nun behob, kann ich nicht sagen.
Ich vermute, es war "Um den „winhttp“ Proxy für x86 Programme zu setzen ist die CMD aus dem Verzeichnis „C:WINDOWSsyswow64“ auszuführen" (Link). Hier hatte ich nämlich scheinbar nur winttp für x64 geändert.
Grüße
Patrick
