--- title: "Unable to Get Local Issuer Certificate: Ursachen und Lösung" description: "„Unable to get local issuer certificate“: Ihr Tool findet die CA nicht, die die Serverkette signiert hat. Drei Ursachen, Lösungen für Python, npm, Git, curl." url: https://proxynet.io/de/blog/unable-to-get-local-issuer-certificate date: 2026-10-06 author: "Acar Diveroli" category: "Anleitungen, Web Scraping" lang: de --- # Unable to Get Local Issuer Certificate: Ursachen und Lösung Sie führen auf einem Firmen-Laptop `npm install` aus, und der Befehl bricht mit `npm error code UNABLE_TO_GET_ISSUER_CERT_LOCALLY` ab. Chrome öffnet die Registry auf demselben Rechner ohne Probleme, und eine Kollegin im Homeoffice installiert dieselben Pakete ohne Fehler. Ein Python-Skript scheitert mit `CERTIFICATE_VERIFY_FAILED`, und `git clone` meldet ein Problem mit dem SSL-Zertifikat. Mit der Registry ist alles in Ordnung: Ihre Tools und Ihr Browser vertrauen unterschiedlichen Listen von Zertifizierungsstellen. Dieser Leitfaden erklärt, was der Client prüft, trennt die drei Ursachen anhand von Fehlern, die wir auf lokalen Testservern nachgestellt haben, und zeigt die Lösung für Python, npm, Git und curl sowie die Korrektur auf der Serverseite. > **Hinweis: Kurzantwort** > > Ihr Client konnte die Zertifikatskette des Servers keinem Stammzertifikat in seiner eigenen Liste vertrauenswürdiger Stammzertifikate zuordnen, dem lokalen Truststore. Drei Ursachen: Der Server lässt sein Zwischenzertifikat weg; ein Proxy oder Antivirenprogramm mit TLS-Inspektion signiert den Verkehr mit einem Stammzertifikat neu, das Ihrem Tool fehlt; oder Ihr Tool liest sein eigenes CA-Bundle statt des Systemspeichers. Hinterlegen Sie das richtige Stammzertifikat dort, wo das Tool sucht (`truststore` oder `REQUESTS_CA_BUNDLE`, `NODE_EXTRA_CA_CERTS`, Schannel oder `http.sslCAInfo`, `--cacert`), oder reparieren Sie die Kette des Servers. `verify=False` und `-k` verstecken den Fehler nur. ## Was bedeutet „unable to get local issuer certificate“? Ein TLS-Zertifikat nennt seinen Inhaber (Subject) und die Zertifizierungsstelle (CA), die es signiert hat (Issuer). Ein Server sendet sein eigenes Zertifikat, das Endzertifikat (Leaf), und dazu ein oder mehrere Zwischenzertifikate, die es mit einem Stammzertifikat verbinden. Stammzertifikate werden beim Verbindungsaufbau nicht mitgeschickt: Jeder Client hat seinen eigenen Satz vertrauenswürdiger Stammzertifikate, den Truststore, und genau diesen Satz meint das „local“ in der Meldung. Der Text ist der OpenSSL-Prüffehler 20, `X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY`. Der Client ist auf ein Zertifikat gestoßen, dessen Aussteller er weder unter den vom Server gesendeten Zertifikaten noch in seinem eigenen Speicher gefunden hat. Der TLS-Handshake bricht ab, bevor Ihre Anfrage gesendet wird. ## Wie funktioniert die Prüfung der Zertifikatskette? 1. **Der Server sendet seine Kette.** Das Endzertifikat kommt zuerst, jedes folgende Zertifikat signiert das vorherige, und das Stammzertifikat darf fehlen, weil Clients es bereits haben ([RFC 8446, Abschnitt 4.4.2](https://www.rfc-editor.org/rfc/rfc8446.html#section-4.4.2)). 2. **Der Client prüft das Endzertifikat:** Der Name muss zum Host in der URL passen, und die Gültigkeitsdaten müssen stimmen. 3. **Der Client sucht jeden Aussteller** unter den gesendeten Zertifikaten, prüft die Signatur und wiederholt das eine Ebene höher. 4. **Die Spitze muss im Truststore enden,** signiert von einem Stammzertifikat, dem der Client bereits vertraut. 5. **Ein fehlendes Glied stoppt den Handshake,** und der Wortlaut hängt davon ab, wo die Kette abbricht. Der Truststore hängt vom Tool ab, nicht vom Rechner. Requests nutzt certifi, ein Python-Paket mit der Stammzertifikatsliste von Mozilla; Node.js kompiliert in jede Version eine Momentaufnahme des Mozilla-Speichers ein; Git for Windows liest seine eigene `ca-bundle.crt` oder den Windows-Speicher. Deshalb kann auf demselben Laptop ein Programm scheitern, während ein anderes funktioniert. ## Drei Fehlermeldungen, eine Familie Wir haben mit OpenSSL ein Stamm-, ein Zwischen- und ein Endzertifikat erzeugt, drei lokale HTTPS-Server gestartet, die unterschiedliche Teile der Kette senden, und sie unter Windows 11 aus Python 3.13.9 (Requests 2.34.2), Node.js 24.11.1 (npm 11.6.2), curl 8.21.0 und Git 2.55 mit OpenSSL aufgerufen. Kein Tool kannte unser Stammzertifikat. | Was der Server gesendet hat | Python (`ssl`, Requests) | Node.js und npm | curl und Git (OpenSSL) | |---|---|---|---| | End- und Zwischenzertifikat | `unable to get local issuer certificate` | `UNABLE_TO_GET_ISSUER_CERT_LOCALLY` | `unable to get local issuer certificate (20)` | | Nur Endzertifikat | `unable to get local issuer certificate` | `UNABLE_TO_VERIFY_LEAF_SIGNATURE` | `unable to get local issuer certificate (20)` | | End-, Zwischen- und Stammzertifikat | `self-signed certificate in certificate chain` | `SELF_SIGNED_CERT_IN_CHAIN` | `self-signed certificate in certificate chain (19)` | Python und curl verwenden für ein fehlendes Zwischenzertifikat und ein unbekanntes Stammzertifikat denselben Wortlaut, deshalb verrät erst die Kette, auf welcher Seite Sie ansetzen müssen. Die dritte Zeile ist dasselbe Problem mit mitgeschicktem Stammzertifikat: Der Server oder ein Proxy dazwischen hat ein Stammzertifikat gesendet, dem Ihr Tool nicht vertraut. ## Die drei Ursachen hinter dem Fehler ### 1. Der Server lässt sein Zwischenzertifikat weg Der Administrator hat nur das Endzertifikat installiert, also scheitert jeder Client ohne das Zwischenzertifikat, in jedem Netz. Browser verdecken das oft: Laut Mozilla bringt Firefox bekannte Zwischenzertifikate schon mit, während andere Browser ein fehlendes im Hintergrund nachladen. Python, Node.js, curl und Git tun weder das eine noch das andere, deshalb beweist „in Chrome funktioniert es“ nichts. ### 2. Ein Proxy oder Antivirenprogramm mit TLS-Inspektion signiert den Verkehr neu Web-Gateways in Unternehmen, Antivirenprogramme mit HTTPS-Scan und Debugging-Tools wie mitmproxy, Charles und Fiddler öffnen die verschlüsselte Verbindung und legen für die Website ein neues Zertifikat vor, signiert mit ihrem eigenen Stammzertifikat. Die IT installiert dieses Stammzertifikat im Systemspeicher verwalteter Laptops, deshalb akzeptieren Browser es; Tools mit eigener Liste tun das nicht. Hinweise: Der Fehler tritt im Büronetz oder im VPN auf, nicht zu Hause, und trifft fast jede Website. Wenn Sie ein solches Tool selbst einsetzen, beschreibt [Was ist ein MITM-Proxy? Charles, Fiddler und mitmproxy](/de/blog/mitm-proxy) den Schritt mit dem Stammzertifikat. ### 3. Ihr Tool vertraut einer anderen Liste als Ihr System Die Bundles von Requests, Node.js und Git sehen weder ein Stammzertifikat, das Ihre Firma in Windows oder macOS installiert hat, noch eine private CA, die interne Dienste signiert. Python aus dem python.org-Installer für macOS braucht aus demselben Grund einen eigenen Zertifikatsschritt, und veralteten Systemen und Bundles können neuere öffentliche Stammzertifikate fehlen. ## Wie finden Sie heraus, welche Ursache vorliegt? Sehen Sie sich die Kette an, die der Server tatsächlich sendet. Git for Windows bringt `openssl` mit, deshalb läuft der Befehl auch in Git Bash: ```bash openssl s_client -connect localhost:47444 -servername localhost -showcerts ca-bundle-plus-corp.pem export REQUESTS_CA_BUNDLE="$PWD/ca-bundle-plus-corp.pem" ``` Danach lieferten sowohl `example.com` als auch unser Testserver `200`. Verwenden Sie nie das Stammzertifikat der Firma allein: Die Variable ersetzt certifi, und in unserem Test scheiterte `example.com` dann mit demselben Fehler. Erstellen Sie die Datei nach jedem Update von certifi neu. Anders als Requests nutzt pip seit Version 24.2 zusätzlich die Zertifikate des Systems ([pip-Dokumentation](https://pip.pypa.io/en/stable/topics/https-certificates/)), deshalb kann `pip install` funktionieren, wo Requests scheitert. Für ein bestimmtes Bundle übergeben Sie `--cert` oder setzen `PIP_CERT`. Unter macOS mit dem python.org-Installer führen Sie einmal `Install Certificates.command` aus. Lässt eine Website, von der Sie Daten erheben, ihr Zwischenzertifikat weg, laden Sie es bei der ausstellenden CA herunter, fügen es der kombinierten Datei hinzu (damit bestand auch unser Server, der nur das Endzertifikat sendet) und informieren den Betreiber. ## Wie beheben Sie den Fehler in Node.js und npm? Die Ausgabe von npm enthält den Fehlercode von Node.js: ```text npm error code UNABLE_TO_GET_ISSUER_CERT_LOCALLY npm error errno UNABLE_TO_GET_ISSUER_CERT_LOCALLY npm error request to https://localhost:47443/demo-pkg failed, reason: unable to get local issuer certificate ``` Node.js ergänzt seine eingebaute Liste um die Stammzertifikate aus der Datei, die `NODE_EXTRA_CA_CERTS` nennt ([Node.js-Dokumentation](https://nodejs.org/api/cli.html#node_extra_ca_certsfile)). npm läuft auf Node.js, also behebt eine Variable beides: ```bash export NODE_EXTRA_CA_CERTS="$PWD/corp-root.pem" npm view demo-pkg version --registry https://localhost:47443/ ``` Der zweite Befehl gab `1.0.0` aus (PowerShell: `$env:NODE_EXTRA_CA_CERTS = "C:\certs\corp-root.pem"`). Node.js liest die Variable nur beim Start, nicht aus einem laufenden Skript heraus. Die npm-eigene Einstellung `cafile` ersetzt dagegen die Liste vertrauenswürdiger Zertifikate. Mit nur dem Stammzertifikat der Firma darin scheiterte unsere Anfrage an die öffentliche Registry: ```text npm error request to https://registry.npmjs.org/left-pad failed, reason: unable to get local issuer certificate ``` Liegt das Stammzertifikat bereits im Systemspeicher, kann Node.js diesen Speicher lesen: `--use-system-ca` kam mit Node.js 23.8.0, `NODE_USE_SYSTEM_CA=1` mit 24.6.0 und 22.19.0, und beide funktionierten in unserem Test mit npm (`NODE_OPTIONS=--use-system-ca`). KI-Coding-Assistenten auf Basis von Node.js lesen dieselben Variablen; die Dokumentation von Claude Code nennt `NODE_EXTRA_CA_CERTS` für Firmen-CAs. ## Wie beheben Sie den Fehler in Git? Mit dem OpenSSL-Backend gibt Git den Wortlaut von curl weiter: ```text fatal: unable to access 'https://localhost:47443/repo.git/': SSL certificate OpenSSL verify result: unable to get local issuer certificate (20) ``` Unter Windows lassen Sie Git den Windows-Speicher nutzen. Der Installer von Git for Windows bietet „Use the OpenSSL library“ (OpenSSL-Bibliothek verwenden) und „Use the native Windows Secure Channel library“ (die eingebaute Secure-Channel-Bibliothek von Windows verwenden) an; Sie können später umstellen: ```bash git config --global http.sslBackend schannel ``` Fehlt das Stammzertifikat auch dort, meldet Schannel `SEC_E_UNTRUSTED_ROOT (0x80090325)` mit einem Text in der Systemsprache, auf einem deutschen Windows: „Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt.“ Schannel ignoriert `http.sslCAInfo`, solange `http.schannelUseSSLCAInfo` nicht gesetzt ist. Unter macOS, Linux oder mit dem OpenSSL-Backend geben Sie Git eine Datei nur für einen einzelnen Server an: ```bash git config --global http.https://git.example.com/.sslCAInfo /path/to/corp-root.pem ``` In unserem Test kam der konfigurierte Host durch TLS, ein anderer Host scheiterte weiterhin, und `github.com` funktionierte weiter. Wenn das Gateway jede Website inspiziert, verwenden Sie Schannel oder eine kombinierte Datei (das Bundle von Git plus das Stammzertifikat der Firma). ## Wie beheben Sie den Fehler in curl? Die Fehlernummer in curl ist 60. Unser curl 8.21.0 formuliert sie wie unten; andere Builds geben `SSL certificate problem: unable to get local issuer certificate` aus: ```text curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20) More details here: https://curl.se/docs/sslcerts.html ``` - **`--cacert corp-root.pem`** prüft gegen diese Datei und ersetzt das Standard-Bundle; nehmen Sie also eine kombinierte Datei, wenn Sie auch öffentliche Websites abrufen. - **`--ca-native`** (curl 8.2.0+) ergänzt OpenSSL-Builds unter Windows um den Systemspeicher, unter macOS dann, wenn curl mit Apples SecTrust gebaut wurde. - **Das Windows-eigene `curl.exe`** nutzt Schannel und den Windows-Speicher. Bei einer privaten CA, die keine Sperrinformationen veröffentlicht, bricht es mit `schannel: the revocation status is unknown` ab; `--ssl-revoke-best-effort` nimmt das hin und prüft die Kette trotzdem. - **`--proxy-cacert`** prüft einen HTTPS-Proxy, also einen, den Sie über eine Proxy-URL mit `https://` erreichen. Ein einfacher `http://`-Proxy hat kein eigenes Zertifikat; [cURL mit Proxy verwenden: HTTP- und SOCKS5-Proxy einrichten](/de/blog/curl-proxy) behandelt beide Fälle. Die Seite des curl-Projekts zur [SSL-Zertifikatsprüfung](https://curl.se/docs/sslcerts.html) empfiehlt nachdrücklich, die Prüfung im Produktivbetrieb nie zu überspringen. ## Warum sind verify=False, -k und NODE_TLS_REJECT_UNAUTHORIZED=0 keine Lösung? Diese Schalter hören auf, die Kette zu prüfen, statt sie zu reparieren. Der Client akzeptiert dann jedes Zertifikat für jeden Namen, auch eines von jemandem im selben Netz, der Ihren Verkehr mitlesen will; die Node.js-Dokumentation nennt `NODE_TLS_REJECT_UNAUTHORIZED=0` ausdrücklich unsicher. In unserem Git-Test erreichte `http.sslVerify=false` den Server ohne jede Warnung, die fehlerhafte Einrichtung bleibt also einfach bestehen. Solche Schalter breiten sich außerdem aus: Eine Variable im Shell-Profil erreicht jedes Node.js-Programm, und ein `verify=False` aus einem Test landet in der Produktion. ## Wie liefert Ihr eigener Server eine vollständige Kette aus? Konfigurieren Sie das Endzertifikat, gefolgt von allen Zwischenzertifikaten, und lassen Sie das Stammzertifikat weg. In nginx enthält die Datei für `ssl_certificate` zuerst das Serverzertifikat und danach die Zwischenzertifikate ([nginx-Dokumentation](https://nginx.org/en/docs/http/configuring_https_servers.html#chains)); bei falscher Reihenfolge verweigert nginx den Start mit `key values mismatch`. Certbot schreibt dafür `fullchain.pem`, während `cert.pem` nur das Endzertifikat enthält; Apache ab 2.4.8 nimmt `fullchain.pem` in `SSLCertificateFile`. Prüfen Sie von außen mit `openssl s_client -connect yourdomain:443 -servername yourdomain -showcerts`: Sie sollten die Einträge `0` und `1` sowie `Verify return code: 0 (ok)` sehen. Zwei Änderungen im Jahr 2026 machen es lohnend, diese Prüfung zu automatisieren. Seit dem 15. März 2026 begrenzen die Baseline Requirements des CA/Browser Forum öffentliche Zertifikate auf 200 Tage (100 ab März 2027, 47 ab März 2029); Verlängerungen kommen also häufiger, und jede ist eine Gelegenheit, die falsche Datei einzuspielen. Am 27. Mai 2026 hat Let's Encrypt sein Standardprofil auf Zwischenzertifikate der Generation Y umgestellt, die die bekannten ISRG-Stammzertifikate über Cross-Signaturen erreichen; Certify The Web, ein Zertifikats-Client für Windows, dokumentiert, dass Windows-Server die kürzere Kette zu den neuen Stammzertifikaten senden, die ältere Clients nicht prüfen können. ## Verursacht ein Proxy diesen Fehler? Nur ein Proxy, der den Verkehr entschlüsselt. Bei einer `https://`-Anfrage über einen HTTP-Proxy sendet der Client `CONNECT host:443`, und der Proxy reicht verschlüsselte Bytes durch; Sie prüfen also das Zertifikat der Website selbst, wie unser einfacher Tunnel gezeigt hat. Auch die Gateways von Proxynet sind einfache Tunnel: Eine Verbindung über einen [HTTPS-Proxy](https://proxynet.io/de/https-proxy) braucht kein Stammzertifikat auf Ihrem Rechner. Wenn Sie per Web Scraping über einen [Residential-Proxy](https://proxynet.io/de/residential-proxy) Daten sammeln, wechselt die Ausgangsadresse, das Zertifikat der Website aber nicht. Ein Kettenfehler bei einem Ziel begleitet Sie deshalb zu jedem Ausgang; rotierende IPs beheben ihn nicht. ## Wo Ihnen dieser Fehler begegnet - **Paketinstallationen auf einem Firmen-Laptop:** npm, pip und yarn scheitern hinter einem Gateway mit TLS-Inspektion, während der Browser funktioniert. - **CI-Runner und Docker-Builds:** Ein Container hat seinen eigenen Truststore, deshalb gehört das Stammzertifikat der Firma ins Image. - **KI-Coding-Assistenten:** Kommandozeilen-Tools auf Basis von Node.js rufen ihre APIs über dasselbe Gateway auf. - **API-Clients:** Öffnen Sie in Postman **Settings** (Einstellungen), dann **Certificates** (Zertifikate), schalten Sie **CA certificates** (CA-Zertifikate) ein und wählen Sie die PEM-Datei aus. - **Scraper:** Eine Website mit fehlendem Zwischenzertifikat scheitert in jedem Skript, öffnet sich aber im Browser. - **Interne Dienste:** Dashboards und Git-Server, die von einer Firmen-CA signiert sind. ## Häufige Fehler - **`REQUESTS_CA_BUNDLE`, `cafile` von npm oder `--cacert` nur auf das Stammzertifikat der Firma zeigen lassen.** Alle drei ersetzen die Standardliste. - **Das falsche Zertifikat hinzufügen.** Die Datei muss das Stammzertifikat enthalten, das die IT bereitstellt, nicht das Endzertifikat einer einzelnen Website. - **Das Zertifikat im binären DER-Format speichern.** Diese Einstellungen erwarten PEM, die Textform, die mit `-----BEGIN CERTIFICATE-----` beginnt. - **`NODE_EXTRA_CA_CERTS` im Skript setzen.** Node.js liest die Variable nur beim Start. - **`cert.pem` statt `fullchain.pem` einspielen.** Browser funktionieren womöglich weiter, deshalb merkt es niemand. ## Entscheidungshilfe | Was Sie sehen | Was zu tun ist | |---|---| | Nur Eintrag `0`, öffentlicher Aussteller | Der Betreiber liefert die vollständige Kette aus; bis dahin das Zwischenzertifikat Ihrem Bundle hinzufügen | | Aussteller ist Ihre Firma, ein Antivirenprogramm oder ein Debugging-Tool | Dieses Stammzertifikat bei der IT holen und pro Tool hinterlegen | | Öffentliche Kette und `0 (ok)`, ein Tool scheitert | Das Tool den Systemspeicher lesen lassen: truststore, `--use-system-ca`, Schannel | | npm scheitert | `NODE_EXTRA_CA_CERTS`; `cafile` nur mit vollständigem Bundle | | Git scheitert bei einem internen Server | `http..sslCAInfo` für diesen Host | | curl scheitert | `--cacert` mit kombinierter Datei oder `--ca-native` | ## Häufige Fragen ### Warum öffnet sich die Website im Browser, scheitert aber in Python, curl oder Node.js? Browser und Tool lesen unterschiedliche Truststores, und Browser ergänzen unvollständige Ketten selbst. Ein Skript liest sein eigenes Bundle und tut nichts davon; vergleichen Sie die Kette mit `openssl s_client`, um zu sehen, was zutrifft. ### Ist es sicher, verify=False, -k oder NODE_TLS_REJECT_UNAUTHORIZED=0 zu verwenden? Nicht als Lösung. Diese Schalter deaktivieren jede Zertifikatsprüfung, sodass jeder zwischen Ihnen und dem Server den Verkehr mitlesen oder verändern kann. Nutzen Sie sie höchstens für einen einzelnen Befehl gegen Ihren eigenen Testserver. ### Was ist der Unterschied zwischen „unable to get local issuer certificate“ und „self-signed certificate in certificate chain“? Beide bedeuten, dass die Kette bei einem Stammzertifikat endet, dem Ihr Tool nicht vertraut. Im ersten Fall wurde das Stammzertifikat nicht gesendet und lokal nicht gefunden; im zweiten hat der Server oder ein Proxy das Stammzertifikat selbst mitgeschickt. Die Lösung ist dieselbe. ### Woher bekomme ich das Stammzertifikat meiner Firma? Von Ihrer IT- oder Sicherheitsabteilung. Auf einem verwalteten Laptop liegt es bereits im Systemspeicher, deshalb funktionieren truststore, `--use-system-ca` und Schannel ohne Datei. Übernehmen Sie ein Stammzertifikat nie aus einer inoffiziellen Quelle: Ein vertrauenswürdiges Stammzertifikat kann für jede Domain signieren. ### Warum funktioniert pip, wenn Requests auf demselben Rechner scheitert? Seit Version 24.2 prüft pip neben certifi auch die Zertifikate des Systems, während Requests nur certifi liest. Das Paket truststore gibt Ihrem Skript dasselbe Verhalten. ### Kann ein Proxy „unable to get local issuer certificate“ auslösen? Nur einer, der den Verkehr entschlüsselt: ein Firmen-Gateway, ein Antivirenprogramm mit HTTPS-Scan oder ein Debugging-Proxy. Ein tunnelnder Proxy, der `CONNECT` nutzt, reicht das Zertifikat der Website unverändert durch. ## Fazit Der Fehler bedeutet, dass Ihr Client das Zertifikat des Servers keinem Stammzertifikat zuordnen konnte, dem er vertraut. `openssl s_client` zeigt den Grund: Ein einzelnes Endzertifikat weist auf den Server, ein Firmen-Aussteller auf TLS-Inspektion, eine saubere öffentliche Kette auf das eigene Bundle Ihres Tools. Hinterlegen Sie das richtige Stammzertifikat dort, wo dieses Tool sucht, und lassen Sie die Prüfung eingeschaltet. Proxys, die den Verkehr tunneln, ohne Zertifikate anzurühren, finden Sie auf unserer Seite zu [Proxy-Diensten](/de/proxy).