Als Zwei-Zeilen-Fehler mich eine halbe Stunde kostete
Ich wollte gestern nur schnell ein paar ComfyUI-Skills für Claude Code installieren. Sollte eine Sache von zehn Sekunden sein: /plugin marketplace add Comfy-Org/comfy-skills, Enter, fertig.
War es nicht.
Failed to clone marketplace repository: SSH authentication failed. Please ensure your SSH keys are configured for GitHub, or use an HTTPS URL insteadErster Versuch, erster Fehler: SSH-Authentifizierung schlägt fehl, „Permission denied (publickey)“. Okay, klarer Fall, kein SSH-Key für GitHub hinterlegt. Also die HTTPS-URL direkt reingeschrieben statt der Kurzform.
Zweiter Versuch, zweiter Fehler, und der war unangenehmer: „SSL certificate problem: unable to get local issuer certificate“. Git konnte der Zertifikatskette nicht mehr trauen.
Auf einem Firmenrechner ist das ein sehr typisches Symptom. Die Firma prüft den Internetverkehr, klinkt sich mit einem eigenen Zertifikat in die HTTPS-Verbindung ein — völlig normal und meistens auch notwendig. Nur: Git für Windows bringt seine eigene kleine Liste an vertrauenswürdigen Zertifizierungsstellen mit und kennt das firmeneigene Zertifikat nicht. Windows selbst kennt es meistens schon, weil die IT es beim Einrichten des Rechners dort hinterlegt hat. Git schaut da nur standardmäßig nicht nach.
Die Lösung war am Ende ein einziger Befehl:
git config --global http.sslbackend schannelDamit sagt man Git: Nutze nicht deine eigene Zertifikatsliste, sondern die von Windows. Und weil dort das Firmenzertifikat schon vertrauenswürdig eingetragen ist, funktioniert die Verbindung sofort.
Direkt danach lief der Marketplace-Import durch, ohne weiteres Zutun.
Was ich daraus mitnehme: Wenn HTTPS-Klone auf einem Firmenrechner mit Zertifikatsfehlern abbrechen, ist meistens nicht das Netzwerk kaputt und auch nicht GitHub, Git schaut einfach in die falsche Zertifikatsschublade. Ein Blick auf http.sslbackend spart einem dann eine Menge Frust.