Invoke-WebRequest ignore SSL - Dein Leitfaden für PowerShell

invoke-webrequest ignore ssl steht für ein sehr konkretes PowerShell-Problem: Ein HTTPS-Endpunkt soll angesprochen werden, aber das Zertifikat wird vom System nicht akzeptiert. In diesem Artikel zeige ich, wie man das in PowerShell 7 mit -SkipCertificateCheck löst, was in Windows PowerShell 5.1 noch möglich ist und warum der schnelle Workaround nur in engen Ausnahmefällen sinnvoll ist. Dazu kommen die typischen Fehlerbilder bei SSL und Zertifikaten, damit man nicht am falschen Hebel ansetzt.

Warum Zertifikatsfehler in PowerShell überhaupt auftreten

Wenn Invoke-WebRequest bei einer HTTPS-Verbindung abbricht, liegt das meist nicht an der Webanfrage selbst, sondern an der Vertrauenskette des Zertifikats. Das System prüft, ob das Zertifikat gültig ist, zum Hostnamen passt, von einer vertrauten Stelle ausgestellt wurde und nicht abgelaufen oder gesperrt ist. Genau an dieser Stelle scheitern in internen Netzen oft Self-Signed-Zertifikate, interne Zertifizierungsstellen oder schnell aufgesetzte Testsysteme.

Typische Ursachen sind in der Praxis erstaunlich banal: ein fehlendes Zwischenzertifikat, ein falscher Name im Zertifikat, eine interne CA, die auf dem Client nicht vertraut wird, oder ein bereits abgelaufenes Zertifikat. Ich trenne diese Fälle bewusst, weil nicht jeder HTTPS-Fehler durch das Ignorieren von SSL gelöst werden kann. Wenn der Server etwa gar nicht erreichbar ist, der Proxy dazwischenfunkt oder die DNS-Auflösung falsch ist, hilft auch kein Zertifikats-Bypass.

• Self-Signed-Zertifikat: häufig in Laboren und bei kurzfristigen Tests.
• Interne CA ohne Trust: der Client kennt die Stammzertifizierungsstelle nicht.
• Ablauf oder Sperrung: das Zertifikat ist technisch korrekt, aber nicht mehr gültig.
• Hostname-Mismatch: der Name im Zertifikat passt nicht zur aufgerufenen Adresse.
• Fehlende Kette: ein Zwischenzertifikat wurde nicht ausgeliefert.

Wenn man die Ursache sauber einordnet, wird die nächste Entscheidung einfach: kurz testen, gezielt freischalten oder die Vertrauenskette richtig aufbauen. Genau dort setzt der direkte PowerShell-Weg an.

Der direkte Weg in PowerShell 7 und neuer

In PowerShell 6.0 und neuer ist der pragmatische Weg klar: Invoke-WebRequest bringt den Schalter -SkipCertificateCheck mit. Damit werden die Zertifikatsprüfungen vollständig übersprungen, also auch Ablauf, Sperrprüfung und Vertrauensstellung. Das ist bequem für Testsysteme, aber ich würde es nie als Standardlösung für produktive Verbindungen behandeln.

Invoke-WebRequest -Uri 'https://lab-intern.local' -SkipCertificateCheck

Für API-Aufrufe gilt dasselbe Prinzip auch bei Invoke-RestMethod, falls du nicht eine HTML-Seite, sondern strukturierte Daten abfragst:

Invoke-RestMethod -Uri 'https://api-lab.local' -SkipCertificateCheck

Der Vorteil ist die Einfachheit: ein Kommando, kein zusätzlicher Code, kein globaler Eingriff. Der Nachteil ist ebenso klar: Die Verifikation fällt komplett weg. Wenn du also versehentlich die falsche Zieladresse, einen manipulierten Proxy oder ein fremdes Zertifikat triffst, bekommst du keine Warnung mehr. Ich nutze das höchstens für kontrollierte Umgebungen, zum Beispiel ein isoliertes Lab, ein lokales Testgerät oder einen kurzlebigen Admin-Check.

Wichtig ist auch die Abgrenzung zu anderen Parametern. -SslProtocol steuert nur, welche TLS-Versionen erlaubt sind, und löst keine Zertifikatsprobleme. Ebenso ist -SkipCertificateCheck kein Ersatz für eine saubere Proxy- oder DNS-Konfiguration. Wenn die Verbindung auf Transportebene schon scheitert, bleibt die Fehlersuche an anderer Stelle hängen.

Für moderne Skripte ist dieser Weg die sauberste Form des temporären Bypasses. In älteren Umgebungen ist das leider nicht immer verfügbar, und genau dort wird es schnell unsauber.

Was in Windows PowerShell 5.1 noch möglich ist

In Windows PowerShell 5.1 gibt es keinen gleichwertigen Parameter wie -SkipCertificateCheck. Wer dort trotzdem Zertifikatsprüfungen umgehen muss, landet oft beim globalen Callback von ServicePointManager. Das funktioniert, hat aber eine breite Wirkung: Die Ausnahme gilt nicht nur für einen einzelnen Request, sondern für alle HTTPS-Anfragen im laufenden Prozess.

$oldCallback = [System.Net.ServicePointManager]::ServerCertificateValidationCallback

try {
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }

    Invoke-WebRequest -Uri 'https://lab-intern.local' -UseBasicParsing
}
finally {
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $oldCallback
}

Genau an dieser Stelle wird aus einem harmlosen Lab-Workaround schnell ein Risiko. Wenn später im selben Prozess noch andere Webzugriffe laufen, werden sie ebenfalls ohne Zertifikatsprüfung ausgeführt. Darum setze ich so etwas nur in einer isolierten, kurzlebigen Sitzung ein und räume den Callback sofort wieder auf. Ein finally-Block ist hier nicht optional, sondern Pflicht.

Ich erwähne bewusst auch -UseBasicParsing, weil es in alten 5.1-Skripten oft ohnehin auftaucht. Mit SSL hat das aber nichts zu tun. Es verhindert keine Zertifikatsfehler, sondern betrifft nur die Art, wie die Antwort verarbeitet wird. Wer diese beiden Themen vermischt, debuggt am Ende am falschen Problem.

Für alles, was über einen einmaligen Test hinausgeht, ist 5.1 damit eigentlich schon das falsche Terrain. Deshalb lohnt sich der Blick auf die saubereren Alternativen.

Die saubereren Alternativen für Test, Staging und Produktion

Wenn ich die Wahl habe, umgehe ich Zertifikatsprüfung nicht, sondern behebe die Vertrauensbeziehung. Das ist in der Praxis meist weniger aufwendig, als es zunächst wirkt, und deutlich stabiler als jeder Bypass. Vor allem in Teams und automatisierten Deployments spart man sich damit eine Menge späterer Nebeneffekte.

Für interne Systeme ist meist die beste Lösung, die eigene Root-CA auf den Client-Rechnern zu verteilen und Serverzertifikate sauber auszustellen. Damit bleiben Skripte unverändert, und die Validierung funktioniert weiterhin so, wie sie soll. Wenn ein Zertifikat nur deshalb fehlschlägt, weil der Hostname nicht passt, ist die Antwort nicht der Bypass, sondern ein Zertifikat mit dem richtigen Subject Alternative Name.

Gerade bei Staging-Umgebungen sieht man oft den Zwischenweg: kurz ein Self-Signed-Zertifikat erzeugen und später „noch schnell“ den Check abschalten. Das ist meist der Punkt, an dem technische Schulden anfangen. Ich halte das nur dann für akzeptabel, wenn der Host isoliert ist, der Zweck klar dokumentiert ist und die Ausnahme zeitlich eng begrenzt bleibt.

Wenn die Umgebung sauber eingerichtet ist, verschwindet auch die Versuchung, Zertifikatsprüfungen einfach zu ignorieren. Danach geht es nur noch darum, typische Fehlannahmen zu vermeiden.

Typische Fehler, die ich in der Praxis immer wieder sehe

Der häufigste Denkfehler ist, SSL-Fehler und Zertifikatsfehler gleichzusetzen. Das ist zu grob. Ein Zertifikats-Bypass hilft nicht gegen Authentifizierungsprobleme, gegen falsche Header, gegen DNS-Probleme oder gegen eine defekte Proxy-Konfiguration. Er hilft nur dort, wo die TLS-Verbindung technisch steht, aber die Zertifikatsprüfung scheitert.

• Host über IP statt Namen aufrufen: Das Zertifikat passt dann oft nicht zum Ziel.
• Callback nicht zurücksetzen: Der Prozess bleibt für alle weiteren Requests unsicher.
• Produktivsysteme ausnehmen: Ein Test-Workaround wird versehentlich dauerhaft übernommen.
• Falsche Fehlerquelle: Das eigentliche Problem liegt bei Proxy, TLS-Version oder DNS.
• Mehrere Requests im selben Prozess: Ein globaler Bypass wirkt weiter, als man denkt.

Ein weiterer Punkt, der oft übersehen wird: Der schnellste Workaround ist selten der beste Systemzustand. Wer Skripte automatisiert, sollte immer prüfen, ob eine Zertifikatsausnahme sauber markiert und später wieder entfernt wird. Ich dokumentiere solche Stellen gern direkt im Skript mit einem klaren Kommentar und, wenn es länger läuft, mit einem Ablauf- oder Prüfdatum im Change-Ticket.

Damit landet man bei der eigentlichen Entscheidungsfrage: Was sollte man im Alltag wirklich wählen, wenn beides möglich wäre?

Was ich im Alltag wirklich empfehlen würde

Meine Reihenfolge ist schlicht: Erst die Vertrauenskette reparieren, dann den Hostnamen und das Zertifikat prüfen, und nur wenn das nicht kurzfristig geht, einen engen temporären Bypass setzen. In PowerShell 7 und neuer ist -SkipCertificateCheck dafür die sauberste Notlösung. In Windows PowerShell 5.1 bleibt der globale Callback nur ein Notbehelf für Legacy-Szenarien, nicht für dauerhafte Betriebsprozesse.

• Einmaliger Lab-Test: -SkipCertificateCheck ist pragmatisch und schnell.
• Älteres 5.1-Skript: Nur mit Callback, isoliert und sofort wieder zurückgesetzt.
• Interne Dauerumgebung: Interne CA und korrekt ausgestellte Zertifikate.
• Produktion: Keine dauerhafte Umgehung, sondern saubere Vertrauensstellung.

Wenn ich eine Ausnahme einbaue, behandle ich sie wie einen temporären Wartungsmodus: klar begrenzt, klar dokumentiert und mit einem sichtbaren Plan zum Entfernen. Genau so bleibt aus einem schnellen Trick keine dauerhafte Sicherheitslücke im Betrieb.