So beheben Sie „SSL-Zertifikatproblem: Lokales Ausstellerzertifikat konnte nicht abgerufen werden“

SSL certificate problem: unable to get local issuer certificatebedeutet, dass Ihr Client keine Vertrauenskette vom Serverzertifikat zu einer vertrauenswürdigen Zertifizierungsstelle aufbauen konnte. Die Versuchung besteht darin, die Überprüfung zu deaktivieren. Tun Sie dies nicht – dadurch wird der Schutz vor Abhören vollständig aufgehoben. Die eigentliche Lösung ist normalerweise unkompliziert.

Was der Fehler bedeutet

Wenn ein Client eine Verbindung über TLS herstellt, präsentiert der Server sein Zertifikat sowie alle Zwischenzertifikate. Der Client muss diese Kette mit einem vertrauenswürdigen Root in seinem lokalen CA-Speicher verknüpfen. Der Fehler tritt auf, wenn ein Link fehlt – entweder hat der Server die Zwischenverbindung nicht gesendet oder Ihr lokaler Trust Store fehlt oder ist veraltet.

Diagnostizieren Sie dies, indem Sie die Kette untersuchen.

openssl s_client -connect example.com:443 -showcerts </dev/null

# Look for the verification result at the end:
#   Verify return code: 0 (ok)
#   Verify return code: 20 (unable to get local issuer certificate)
#   Verify return code: 21 (unable to verify the first certificate)

Rückkehrcode21 bedeutet im Allgemeinen, dass der Server schuld ist – er hat sein Zwischenzertifikat nicht gesendet. Rückkehrcode20 Im Allgemeinen bedeutet dies, dass Ihr lokaler Trust Store das Problem ist.

Ursache 1: Der Server sendet keine Zwischennachrichten

Eine häufige Serverfehlkonfiguration. Browser verbergen es oft, weil sie Zwischendaten früherer Besuche zwischenspeichern, sodass die Website „in Chrome funktioniert“, während Curl und Ihre CI-Pipeline ausfallen.

# Count the certificates the server sends
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"
# 1 means only the leaf — the intermediate is missing

Wenn Sie den Server kontrollieren, beheben Sie das Problem dort. Nginx benötigt das Blatt und die Zwischenprodukte, die in dieser Reihenfolge in einer Datei verkettet sind.

# Correct order: leaf first, then intermediates
cat leaf.crt intermediate.crt > fullchain.crt

server {
    # Use the full chain, not just the leaf certificate
    ssl_certificate     /etc/ssl/certs/fullchain.crt;
    ssl_certificate_key /etc/ssl/private/privkey.key;
}

Certbotsfullchain.pem enthält bereits die Kette – zeigt Nginx aufcert.pem ist stattdessen die häufigste Ursache für diesen Fehler auf Let’s Encrypt-Sites.

Ursache 2: Ein veraltetes oder fehlendes CA-Bundle

Wenn die Serverkette vollständig ist, ist Ihr lokaler Trust Store veraltet.

# Debian / Ubuntu
sudo apt update && sudo apt install --reinstall ca-certificates
sudo update-ca-certificates

# RHEL / Fedora
sudo dnf reinstall ca-certificates
sudo update-ca-trust

# Alpine (very common in Docker images)
apk add --no-cache ca-certificates
update-ca-certificates

# macOS
brew install ca-certificates
# or update curl, which bundles its own
brew install curl

Minimale Docker-Images sind eine häufige Ursache für diesen Fehler, da sie ohne CA-Bundle ausgeliefert werden. Hinzufügen vonca-certificates zum Bild löst es normalerweise in einer Zeile auf.

Ursache 3: Unternehmens-TLS-Abfangen

Viele Unternehmensnetzwerke fangen TLS ab und legen ihr eigenes, von einer internen Zertifizierungsstelle signiertes Zertifikat vor. Browser funktionieren, weil die Zertifizierungsstelle über die Geräteverwaltung auf Betriebssystemebene installiert wird. Befehlszeilentools mit eigenen Trust Stores tun dies nicht.

Die Lösung besteht darin, die Stammzertifizierungsstelle des Unternehmens zum entsprechenden Trust Store hinzuzufügen – und nicht darin, die Überprüfung zu deaktivieren.

# Capture the certificate the proxy is presenting
openssl s_client -showcerts -connect example.com:443 </dev/null \
  | openssl x509 -outform PEM > corp-ca.crt

# Inspect it to confirm what it is
openssl x509 -in corp-ca.crt -noout -subject -issuer -dates

# Install system-wide (Debian/Ubuntu)
sudo cp corp-ca.crt /usr/local/share/ca-certificates/corp-ca.crt
sudo update-ca-certificates

Fragen Sie Ihre IT-Abteilung nach der offiziellen Root-CA-Datei, anstatt sie nach Möglichkeit selbst zu extrahieren. Beim Extrahieren aus einer Live-Verbindung wird davon ausgegangen, dass die Verbindung nicht bereits gefährdet ist.

Korrekturen pro Tool

Locken

# Point at a specific bundle
curl --cacert /path/to/ca-bundle.crt https://example.com

# Or set it for the session
export CURL_CA_BUNDLE=/path/to/ca-bundle.crt

Git

# Correct fix: point Git at a valid bundle
git config --global http.sslCAInfo /path/to/ca-bundle.crt

# Scope it to one host if only that host is affected
git config --global http."https://internal.company.com/".sslCAInfo /path/to/corp-ca.crt

git config --global http.sslVerify false erscheint in jedem Suchergebnis für diesen Fehler. Es deaktiviert die Zertifikatsüberprüfung für jeden Host, von dem Sie jemals klonen, dauerhaft. Benutzen Sie es nicht.

Node.js

# Add a CA to Node's trust store for this process
export NODE_EXTRA_CA_CERTS=/path/to/corp-ca.crt
node app.js

// Or per-request, which is more precise
import https from 'node:https';
import fs from 'node:fs';

const agent = new https.Agent({
  ca: fs.readFileSync('/path/to/corp-ca.crt'),
});

await fetch('https://internal.example.com', { agent });

NODE_TLS_REJECT_UNAUTHORIZED=0 Deaktiviert die Überprüfung im gesamten Prozess und Node gibt eine Warnung aus, die genau das besagt. Es ist in einem lokalen Wegwerftest akzeptabel und nirgendwo anders.

Python

import certifi, requests

# Use certifi's bundle explicitly
requests.get('https://example.com', verify=certifi.where())

# Or a corporate CA
requests.get('https://internal.example.com', verify='/path/to/corp-ca.crt')

# Environment variables respected by requests and urllib3
export REQUESTS_CA_BUNDLE=/path/to/ca-bundle.crt
export SSL_CERT_FILE=/path/to/ca-bundle.crt

# Keep certifi current
pip install --upgrade certifi

Docker

FROM node:22-alpine

# Alpine ships without a CA bundle
RUN apk add --no-cache ca-certificates

# Add a corporate CA if you are behind interception
COPY corp-ca.crt /usr/local/share/ca-certificates/
RUN update-ca-certificates

ENV NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt

Ursache 4: Das Zertifikat ist abgelaufen

Überprüfen Sie dies, bevor Sie von einem Truststore-Problem ausgehen.

echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates
# notBefore=...
# notAfter=...

Überprüfen Sie auch die Uhr des Kunden. Eine Maschine mit einem völlig falschen Datum lehnt gültige Zertifikate als noch nicht gültig oder abgelaufen ab, wodurch angehaltene Container und virtuelle Maschinen abgefangen werden.

date
timedatectl status    # Linux

Diagnosesequenz

1. openssl s_client -connect host:443 -showcerts – Lesen Sie den Verifizierungs-Rückgabecode
2. Zählen Sie die gesendeten Zertifikate. Eins bedeutet ein fehlendes Intermediate auf dem Server.
3. Überprüfen Sie die Ablaufdaten und die lokale Systemuhr.
4. Vergleichen Sie es mit einem anderen Computer oder Netzwerk – wenn es dort funktioniert, ist das Problem lokal.
5. Überprüfen Sie, ob der Emittent Ihre Unternehmens-CA ist, was auf ein Abfangen hinweist.
6. Aktualisierenca-certificates und jedes sprachspezifische Paket.

Warum nicht einfach die Verifizierung deaktivieren

Denn die Zertifikatsüberprüfung ist der gesamte Mechanismus, der verhindert, dass sich jemand im Netzwerk als der Server ausgibt, mit dem Sie zu sprechen glauben. Wenn Sie es deaktivieren, kann jeder Vermittler den Datenverkehr lesen und ändern – einschließlich Anmeldeinformationen, Token und der von Ihnen heruntergeladenen Pakete.

Das realistische Risiko ist nicht theoretisch. Eine CI-Pipeline mit deaktivierter Überprüfung installiert problemlos ein Paket aus einer imitierten Registrierung. Die Reparatur dauert nur wenige Minuten; Die Folge des Überspringens kann ein kompromittierter Build sein.

Häufig gestellte Fragen

F: Warum funktioniert es in meinem Browser, aber nicht in Curl?
A: Browser speichern Zwischenzertifikate von früheren Verbindungen im Cache und können fehlende Zertifikate automatisch abrufen. Curl tut weder das eine noch das andere, sodass es ein serverseitiges Kettenproblem aufdeckt, das von Browsern ausgeblendet wird.

F: Was ist der Unterschied zwischen Fehler 20 und Fehler 21?
A: 21 bedeutet, dass der Client das erste Zertifikat nicht überprüfen konnte, normalerweise weil keine Zwischenzertifikate gesendet wurden. 20 bedeutet, dass der Aussteller in Ihrem lokalen Trust Store nicht gefunden wurde.

F: Wo ist das CA-Bundle auf meinem System?
A: Im Allgemeinen/etc/ssl/certs/ca-certificates.crt auf Debian und Ubuntu,/etc/pki/tls/certs/ca-bundle.crt auf RHEL. In Pythonpython -m certifi Gibt den Pfad aus, den das Zertifikat verwendet.

F: Ist es sicher, die Verifizierung nur für die lokale Entwicklung zu deaktivieren?
A: Fügen Sie bei einem lokalen Server mit einem selbstsignierten Zertifikat dieses Zertifikat stattdessen zu Ihrem Truststore hinzu – es dauert genauso lange und führt nicht zur Gewohnheit, Ihnen in die Produktionskonfiguration zu folgen.

F: Mein CI funktioniert, aber die Produktion schlägt fehl. Warum?
A: Fast immer ein Unterschied im Basisbild. In schlanken und alpinen Bildern wirdca-certificateshäufig weggelassen vollständig.

Fazit

Dieser Fehler bedeutet, dass die Vertrauenskette unterbrochen ist, und es gibt nur wenige Ursachen:Der Server sendet seine Zwischenzertifikate nicht, Ihr lokales CA-Bundle fehlt oder ist veraltet, ein Unternehmens-Proxy fängt TLS mit seiner eigenen CA ab oder ein Zertifikat ist abgelaufen. Diagnose mitopenssl s_client und den Rückkehrcode überprüfen, dann die eigentliche Ursache beheben – CA installieren,ca-certificatesaktualisieren , oder bedienen Sie die gesamte Kette. Deaktivieren Sie niemals die Überprüfung außerhalb eines einmaligen lokalen Tests, da dadurch der Schutz, den der Fehler bieten soll, aufgehoben wird.