Bei HTTPS-Fehlern in Wget geht es fast nie nur um ein kaputtes Zertifikat, sondern um die Frage, ob die Gegenstelle wirklich die ist, die sie vorgibt zu sein. Genau darum dreht sich das, was viele mit wget ignore ssl meinen: die Zertifikatsprüfung abschalten, den Fehler richtig einordnen und wissen, wann ein Workaround vertretbar ist. Ich zeige hier die direkte Option, die saubere Alternative über eigene CA-Bundles und die Fälle, in denen ich die Prüfung niemals deaktivieren würde.
Die Entscheidung ist meist kleiner, als sie wirkt
- --no-check-certificate schaltet die Prüfung von Zertifikat und Hostname ab, nicht nur einen Teil davon.
- Die Option ist für schnelle Diagnose oder isolierte Umgebungen brauchbar, für produktive Downloads aber riskant.
- Bei internen Zertifikaten ist ein eigener CA-Store fast immer die bessere Lösung.
- In .wgetrc lässt sich die Prüfung dauerhaft mit check_certificate = off deaktivieren, was ich nur sehr gezielt einsetzen würde.
- Wenn Wget die Option nicht kennt oder trotzdem scheitert, steckt oft ein älteres Build, fehlende SSL-Unterstützung oder ein anderes TLS-Problem dahinter.
Warum Wget Zertifikate überhaupt prüft
Wget behandelt HTTPS nicht als bloßen Transportweg, sondern als Vertrauensfrage. Bevor ein Download startet, prüft das Programm die Zertifikatskette, die Gültigkeit des Zertifikats und den Abgleich zwischen Hostname und Zertifikat. Fällt einer dieser Punkte durch, bricht Wget ab, weil sonst ein Man-in-the-Middle-Angriff oder schlicht eine falsch konfigurierte Gegenstelle unbemerkt durchrutschen könnte.
In der Praxis sind die häufigsten Ursachen erstaunlich banal: ein selbstsigniertes Zertifikat, ein abgelaufenes Zertifikat, ein internes Zertifikat ohne passende CA oder ein Hostname, der nicht zum Zertifikat passt. Gerade in Firmenumgebungen sehe ich oft zusätzlich TLS-Inspection durch Proxy-Systeme. Technisch ist das nicht automatisch falsch, aber Wget muss dann der internen CA vertrauen, sonst scheitert die Prüfung konsequent.
| Ursache | Typische Bedeutung | Was ich zuerst prüfe |
|---|---|---|
| Selbstsigniertes Zertifikat | Es gibt keine vertrauenswürdige CA-Kette | Ob ein internes Root- oder Intermediate-Zertifikat fehlt |
| Hostname passt nicht | Zertifikat ist für einen anderen Namen ausgestellt | DNS, Reverse Proxy und SAN-Einträge im Zertifikat |
| Zertifikat abgelaufen | Die Gültigkeit ist beendet | Erneuerung beim Server oder Load Balancer |
| CA-Store veraltet | Das System kennt die ausstellende CA nicht | Aktualisierung der CA-Pakete auf dem Zielsystem |
| TLS-Inspection im Netz | Ein Proxy ersetzt das Zertifikat unterwegs | Ob die Firmen-CA im Trust Store liegt |
Wenn man diese Ursache sauber einordnet, wird die Entscheidung für oder gegen das Abschalten der Prüfung deutlich einfacher. Genau dort setze ich mit der nächsten, schnellen Ausnahme an.
Die schnelle Ausnahme mit der unsicheren Option
Die direkte Variante ist einfach: Wget startet den Download, ohne die Serverzertifikate gegen bekannte Zertifizierungsstellen zu prüfen. Das ist die Funktion, die hinter dem Wunsch steht, SSL in Wget zu ignorieren. Für einen kurzfristigen Test sieht die Syntax so aus:
wget --no-check-certificate Wenn ich den Download sauber benennen oder in ein bestimmtes Verzeichnis schreiben will, kombiniere ich die Option ganz normal mit den übrigen Parametern:
wget --no-check-certificate -O datei.zip
wget --no-check-certificate -P /tmp/downloads Für wiederkehrende lokale Tests kann man die Prüfung auch in der Startkonfiguration deaktivieren:
check_certificate = offDas funktioniert über .wgetrc, also die persönliche Wget-Konfigurationsdatei. Ich würde das nur in sehr kontrollierten Umgebungen machen, etwa auf einem isolierten Testsystem oder bei einem einmaligen Bootstrapping-Schritt. Sobald der Download Teil eines regulären Workflows ist, ist diese Abkürzung zu grob.
Wichtig ist noch ein Detail: Mit der Option wird nicht nur die CA-Prüfung umgangen, sondern auch der Hostname-Abgleich. Genau deshalb ist sie eher ein Notnagel als eine saubere Lösung. Und damit sind wir direkt bei der Frage, wann dieser Notnagel überhaupt vertretbar ist.
Wann ich die Prüfung abschalte und wann nicht
Ich trenne hier sehr klar zwischen diagnostischer Nutzung und produktiver Nutzung. Für einen ersten Blick auf ein internes System kann das Abschalten der Prüfung sinnvoll sein. Für alles, was vertrauliche Daten transportiert, in CI/CD läuft oder aus dem Internet kommt, ist es aus meiner Sicht die falsche Entscheidung.
| Szenario | Meine Einschätzung | Grund |
|---|---|---|
| Internes Labor mit selbstsigniertem Zertifikat | Vertretbar, kurzzeitig | Die Umgebung ist kontrolliert und dient oft nur dem Test |
| Notfallzugriff auf ein Appliance-Interface | Vertretbar, wenn isoliert | Schneller Zugriff kann wichtiger sein als Komfort, aber nicht als Dauerlösung |
| Öffentliche Downloads aus dem Internet | Nicht vertretbar | Zu hohes Risiko für Manipulation und Datenverlust |
| Automatisierte Jobs auf Shared Runnern | Nicht vertretbar | Schwer zu auditieren, schwer zu kontrollieren |
| Vertrauliche Daten oder Zugangsdaten | Klare Ablehnung | Die Integrität der Verbindung ist dann nicht verhandelbar |
Meine Faustregel ist simpel: Wenn ich einem Zertifikat nicht traue, repariere ich das Vertrauen statt die Kontrolle auszuschalten. Genau deshalb lohnt sich der Blick auf die besseren Alternativen.
Sauberere Alternativen für interne Zertifikate
In der Mehrheit der Fälle braucht man keinen unsicheren Modus, sondern nur die richtige Vertrauenskette. Das ist besonders wichtig in Unternehmen, Labors, bei Reverse Proxies und bei Systemen mit eigener PKI. Wget kann mit einer passenden CA-Datei oder einem CA-Verzeichnis genauso gut arbeiten wie mit dem System-Store.
| Alternative | Wann ich sie bevorzuge | Vorteil |
|---|---|---|
| --ca-certificate=... | Einzelnes internes CA-Bundle oder eine portable Automatisierung | Gezielt, klar nachvollziehbar, ohne globale Abschaltung |
| --ca-directory=... | Mehrere interne CAs oder größere Zertifikatsbestände | Skaliert besser als eine einzelne Bundle-Datei |
| System-Trust-Store aktualisieren | Server, Arbeitsplätze und dauerhafte Umgebungen | Alle Tools profitieren davon, nicht nur Wget |
| Zertifikat am Server korrigieren | Hostname-, SAN- oder Ablaufprobleme | Behebt die eigentliche Ursache |
| --pinnedpubkey | Sehr kontrollierte Umgebungen mit fester Serveridentität | Bindet die Prüfung an einen konkreten Schlüssel statt an eine allgemeine CA-Kette |
Für Linux-Systeme ist der Weg über den Trust Store meistens der robusteste. Auf Debian- und Ubuntu-nahen Systemen landet ein internes Root-Zertifikat typischerweise im CA-Store und wird dann systemweit genutzt; auf RHEL- und Fedora-basierten Systemen läuft das über die Trust-Verwaltung der Plattform. Der Effekt ist derselbe: Wget muss die Prüfung nicht abschalten, sondern kann dem Zertifikat wieder normal vertrauen.
Ich empfehle außerdem, den Hostnamen zu prüfen, wenn die Fehlermeldung nach einem Namensabgleich klingt. Ein korrekt ausgestelltes Zertifikat mit falschem DNS-Namen bleibt trotzdem falsch. Und genau dort stolpern viele Setups, die eigentlich nur ein Reverse-Proxy- oder SAN-Problem haben.
Was tun, wenn Wget trotzdem meckert
Wenn die Option nicht hilft oder sogar als unbekanntes Argument endet, ist das kein normales Zertifikatsproblem mehr. Dann prüfe ich zuerst die Wget-Version und die Build-Optionen. Ältere oder stark abgespeckte Builds kennen die Option unter Umständen nicht, oder Wget wurde ohne SSL-Unterstützung kompiliert. In dem Fall kann das Programm HTTPS entweder gar nicht oder nicht vollständig behandeln.
- „unrecognized option“ deutet oft auf eine zu alte oder unvollständige Wget-Build-Version hin.
- Ein anderer SSL-Fehler trotz Option kann auf ein Protokollproblem, einen kaputten TLS-Handshake oder einen zu alten Server hindeuten.
- Fehler nur im Firmennetz sprechen häufig für einen Proxy mit eigener Zertifikatskette.
- Fehler nur bei einem Hostnamen weisen oft auf SAN-, DNS- oder Proxy-Misconfiguration hin.
Ein praktischer Prüfpunkt ist für mich immer die Frage, ob wirklich die Zertifikatsvalidierung scheitert oder schon der TLS-Handshake selbst. Das ist ein wichtiger Unterschied, weil ein unsicherer Schalter nur das erste Problem adressiert. Wenn die Verbindung an Protokoll, Cipher oder Serverkonfiguration scheitert, muss man an einer anderen Stelle ansetzen.
Für mich ist das auch der Punkt, an dem ich in Automatisierungen sehr vorsichtig werde. Ein Skript, das stillschweigend die Prüfung ignoriert, erzeugt langfristig mehr Aufwand als es spart. Besser ist ein sauberer Fehler, der auf die echte Ursache zeigt, als ein Download, der nur scheinbar funktioniert.
Die pragmatische Entscheidung für den Alltag
Wenn ich den Einsatz von Wget in produktiven Umgebungen bewerte, halte ich mich an eine einfache Reihenfolge: Erst Zertifikatskette und Hostname reparieren, dann den CA-Store aktualisieren, erst ganz am Ende die Prüfung temporär abschalten. Genau so bleibt die Verbindung nachvollziehbar und der Download bleibt überprüfbar.
Für interne Systeme ist der beste Weg meistens nicht die unsichere Abkürzung, sondern eine kleine Infrastruktur-Korrektur: internes Root-Zertifikat verteilen, Reverse Proxy sauber konfigurieren, Hostname und Zertifikat angleichen. Das kostet oft weniger Zeit, als man im ersten Moment denkt, und erspart später viele Diskussionen in Betrieb und Security.
Wenn du nur eine Regel mitnimmst, dann diese: Die SSL-Prüfung in Wget abschalten ist ein Werkzeug für Ausnahmefälle, nicht für Standards. Für alles, was länger lebt als ein kurzer Test, gehört die Vertrauensbasis in Ordnung gebracht, nicht umgangen.
