Zum Inhalt springen
EVI Solutions

SSL-Zertifikatfehler im Code: erkennen und beheben

Mittel 20 Min. Aktualisiert:

Kurze Antwort

Ein SSL-Zertifikatfehler im Code entsteht meist durch ein abgelaufenes Zertifikat, fehlendes Vertrauen in die Zertifikatskette oder einen falschen Hostnamen. Die Lösung liegt in der Prüfung des Ablaufdatums, der Aktualisierung des CA-Speichers und der korrekten Client-Konfiguration, nicht im Deaktivieren der Prüfung.

So erkennen Sie das Problem

  • Die Anwendung wirft den Fehler `CERT_HAS_EXPIRED` oder `certificate has expired`
  • Es erscheint `UNABLE_TO_VERIFY_LEAF_SIGNATURE` oder `self signed certificate in certificate chain`
  • `ERR_TLS_CERT_ALTNAME_INVALID` wegen eines falschen Hostnamens
  • Die Verbindung funktioniert im Browser, aber nicht im Code
  • Der Fehler tritt nur in einer Umgebung auf (z. B. Staging)

Häufigste Ursachen

Abgelaufenes Zertifikat

Das Zertifikat auf dem Server ist abgelaufen oder der Client hat eine ältere Kette im Cache gespeichert. Prüfen Sie das Gültigkeitsdatum und leeren Sie den Cache.

Nicht vertrauenswürdige Zertifizierungsstelle (CA)

Der Client erkennt die CA, die das Zertifikat ausgestellt hat, nicht an, was bei internen oder selbstsignierten Zertifikaten häufig vorkommt. Die CA muss dem Vertrauensspeicher hinzugefügt werden.

Falscher Hostname

Das Zertifikat wurde für einen anderen Namen ausgestellt (z. B. `example.com` statt `api.example.com`). Prüfen Sie das SAN-Feld und die Art und Weise, wie der Client zugreift.

Fehlerhafte Zertifikatskette

Der Server sendet nicht die vollständigen Intermediate-Zertifikate, sodass der Client die Kette nicht bis zum Root aufbauen kann. Die Lösung ist eine korrekte Serverkonfiguration.

Falsche Systemzeit

Wenn die Uhr auf dem Rechner oder im Container falsch ist, erscheint ein gültiges Zertifikat als abgelaufen oder noch nicht gültig.

Lösung Schritt für Schritt

  1. 1

    Lesen Sie die genaue Fehlermeldung

    Suchen Sie im Log nach dem Fehlercode (z. B. CERT_HAS_EXPIRED, UNABLE_TO_VERIFY_LEAF_SIGNATURE, ERR_TLS_CERT_ALTNAME_INVALID). Unterschiedliche Codes deuten auf unterschiedliche Ursachen hin, überspringen Sie diesen Schritt daher nicht.

  2. 2

    Prüfen Sie das Gültigkeitsdatum des Zertifikats

    Öffnen Sie die Website im Browser und klicken Sie auf das Schloss neben der Adresse. In den Zertifikatsdetails sehen Sie das Start- und Enddatum der Gültigkeit. Alternativ führen Sie im Terminal openssl s_client -connect host:443 -servername host -text aus und prüfen die Felder Not Before und Not After.

  3. 3

    Prüfen Sie, ob der Hostname übereinstimmt

    Suchen Sie in derselben openssl-Ausgabe das Feld Subject Alternative Name. Es muss den Namen enthalten, den Sie im Code verwenden. Wenn Sie über eine IP-Adresse zugreifen, ist das Zertifikat wahrscheinlich ungültig.

  4. 4

    Aktualisieren Sie den CA-Speicher auf dem System

    Führen Sie unter Windows (als Administrator) certutil -generateSSTFromWU roots.sst und dann certutil -addstore root roots.sst aus; ein einzelnes Zertifikat fügen Sie mit certutil -addstore root zertifikat.crt hinzu. Fügen Sie nur CAs hinzu, denen Sie vertrauen. Unter Linux (Debian/Ubuntu) sudo update-ca-certificates, unter macOS doppelklicken Sie auf die .crt-Datei, fügen sie zum System-Schlüsselbund hinzu und setzen Always Trust für diese CA.

  5. 5

    Fügen Sie die interne CA im Code hinzu

    Wenn Sie ein internes oder selbstsigniertes Zertifikat verwenden, übergeben Sie im Code den Pfad zur CA-Datei. In Node.js ist das die Option ca in https.request oder die Umgebungsvariable NODE_EXTRA_CA_CERTS=/pfad/zur/ca.crt. In Python requests verwenden Sie verify='/pfad/zur/ca.crt'.

  6. 6

    Korrigieren Sie die Kette auf dem Server

    Stellen Sie sicher, dass der Server vollständige Zertifikatsketten sendet. In der Nginx-Konfiguration sollte ssl_certificate das Serverzertifikat und die Liste der Intermediate-Zertifikate enthalten, wobei das Serverzertifikat an erster Stelle steht. Prüfen Sie mit openssl s_client -showcerts -servername host -connect host:443.

  7. 7

    Prüfen Sie die Systemzeit

    Unter Windows (als Administrator) w32tm /resync, unter Linux timedatectl und sudo systemctl restart systemd-timesyncd. Prüfen Sie in Docker-Containern, ob die Zeit mit dem Host synchronisiert ist.

  8. 8

    Umgehen Sie die Prüfung vorübergehend nur in der Entwicklung

    Wenn Sie die Entwicklung fortsetzen müssen, deaktivieren Sie die Prüfung vorübergehend, aber niemals in der Produktion. In Node.js NODE_TLS_REJECT_UNAUTHORIZED=0 (nur lokal), in Python verify=False mit urllib3.disable_warnings(). Entfernen Sie dies unbedingt vor dem Commit.

Wenn nichts hilft: Problem isolieren

Wenn der Fehler weiterhin besteht, erstellen Sie ein minimales reproduzierbares Beispiel: ein Skript, das nur eine TLS-Verbindung zum selben Host aufbaut. Testen Sie es aus verschiedenen Netzwerken und auf verschiedenen Rechnern. Vergleichen Sie die Ausgabe von openssl s_client mit dem, was der Client sieht. Prüfen Sie, ob ein Proxy oder Antivirus den Datenverkehr abfängt und das Zertifikat ändert. Prüfen Sie in Docker, ob im Container CA-Zertifikate installiert sind (Paket ca-certificates). Wenn das Problem nur in der Produktion auftritt, vergleichen Sie die Umgebungskonfiguration und die Client-Versionen. Für komplexe Ketten und mTLS verwenden Sie Tools wie openssl verify und curl -v, um den genauen Ablauf zu sehen.

So beugen Sie vor

  • Prüfen Sie regelmäßig die Ablaufdaten der Zertifikate und legen Sie Erinnerungen an
  • Verwenden Sie die automatische Erneuerung (z. B. Let's Encrypt) und testen Sie die Erneuerung
  • Verwenden Sie in der Entwicklung `mkcert` für lokale Zertifikate, anstatt die Prüfung dauerhaft zu deaktivieren
  • Committen Sie niemals Code, der `rejectUnauthorized: false` oder `verify=False` enthält

Wann Sie einen Profi rufen sollten

Wenn der Fehler mTLS, komplexe Zertifikatsketten betrifft oder nur auf Produktionsservern auftritt, rufen Sie den IT-Support an, um das Problem ohne Risiko einer Betriebsunterbrechung zu isolieren.

Überlassen Sie es uns KI-IT-Assistent fragen
Software- und Produktentwicklung · Individuelle Apps, SaaS und ein MVP in 4 bis 8 Wochen

Häufige Fragen

Warum erscheint `self signed certificate in certificate chain`?

Das bedeutet, dass der Client dem Zertifikat in der Kette nicht vertraut, meist weil es selbstsigniert ist oder von einer internen CA stammt. Die Lösung besteht darin, diese CA dem Vertrauensspeicher hinzuzufügen oder im Code den Pfad zur CA-Datei zu übergeben.

Ist es sicher, die Zertifikatsprüfung im Code zu deaktivieren?

Nein, das Deaktivieren der Prüfung (`rejectUnauthorized: false` oder `verify=False`) macht die Anwendung anfällig für Man-in-the-Middle-Angriffe. Verwenden Sie es nur vorübergehend in der lokalen Entwicklung und niemals in der Produktion.

Wie prüfe ich, welches Zertifikat der Server tatsächlich sendet?

Führen Sie `openssl s_client -connect host:443 -servername host -showcerts -text` aus. In der Ausgabe sehen Sie alle Zertifikate in der Kette, und der Textteil zeigt die Details des Serverzertifikats, einschließlich Gültigkeitsdaten und SAN-Feldern.

Teilen
Keine Lösung gefunden?Der KI-IT-Assistent ist rund um die Uhr erreichbar. Beschreiben Sie das Problem oder senden Sie einen Screenshot und erhalten Sie eine Anleitung für Ihren Fall.KI-IT-Assistent fragen