Der Fehler postman unable to verify the first certificate ist meistens kein Hinweis auf ein grundsätzlich kaputtes HTTPS, sondern auf eine unterbrochene Zertifikatskette. In diesem Artikel zeige ich, was die Meldung technisch bedeutet, warum sie in Postman auftaucht und wie du sie sauber behebst, ohne unnötig an der Sicherheit vorbei zu arbeiten.
Woran der Fehler liegt und wie du ihn schnell eingrenzt
- Die Meldung deutet fast immer auf eine unvollständige oder nicht vertrauenswürdige SSL-Zertifikatskette hin.
- Am häufigsten fehlen Intermediate-Zertifikate oder die passende CA ist in Postman nicht bekannt.
- Das Deaktivieren der SSL-Prüfung hilft nur als Diagnose, nicht als dauerhafte Lösung.
- In internen Netzen spielen mTLS, Proxy-Inspection und lokale Trust Stores oft eine größere Rolle als der eigentliche API-Endpunkt.
- Postman speichert Zertifikate lokal, deshalb kann derselbe Request auf einem anderen Rechner anders reagieren.
- Die Postman Console zeigt dir oft schneller die eigentliche Ursache als der Fehlertext in der Oberfläche.
Was die Meldung technisch bedeutet
Ich lese diesen Fehler immer als Hinweis auf die Zertifikatsprüfung zwischen Client und Server, nicht als generelle Aussage über HTTPS. Postman baut beim Verbindungsaufbau die Kette vom Serverzertifikat über mögliche Zwischenzertifikate bis zu einer vertrauenswürdigen Root-CA auf. Genau dort scheitert der Prozess, wenn ein Glied fehlt, falsch ausgeliefert wird oder in deinem lokalen Trust Store nicht bekannt ist.
Wichtig ist die Unterscheidung zwischen drei Dingen: Das Leaf-Zertifikat ist das eigentliche Serverzertifikat, Intermediate-Zertifikate verbinden es mit der CA, und die Root-CA ist der Vertrauensanker. Fehlt ein Intermediate, sieht Postman oft nur die Spitze der Kette und bricht mit der Verifikation ab. Das ist technisch unschön, aber in der Praxis sehr gut eingrenzbar.
Genau deshalb ist die Frage nicht nur, wie man den Fehler ausblendet, sondern warum die Kette nicht vollständig ist. Darauf gehe ich im nächsten Abschnitt systematisch ein.
Warum die Zertifikatskette in der Praxis bricht
Die Ursachen sind meistens banaler, als die Fehlermeldung klingt. In Unternehmensnetzen, Entwicklungsumgebungen und bei internen APIs sehe ich immer wieder dieselben Muster: ein fehlendes Zwischenzertifikat, eine interne CA, die nicht importiert wurde, oder ein Proxy, der TLS sichtbar mitliest und neu signiert.
| Ursache | Typisches Bild | Was ich zuerst prüfe |
|---|---|---|
| Fehlendes Intermediate-Zertifikat | Browser oder andere Tools melden ebenfalls eine unvollständige Kette | Ob der Server die komplette Kette ausliefert |
| Interne oder selbstsignierte CA | Funktioniert nur auf manchen Rechnern oder nach Import einer CA | Ob die passende Root- oder CA-Datei in Postman hinterlegt ist |
| Mutual TLS ohne Client-Zertifikat | Der Server erwartet zusätzlich ein Client-Zertifikat | Ob Host, Port und Zertifikatstyp in Postman korrekt zugeordnet sind |
| Proxy oder Security Gateway | Im Browser geht es, in Postman aber nicht oder umgekehrt | Ob ein Unternehmensproxy TLS terminiert und neu signiert |
| Falscher Host, Port oder falsches Ziel | Das Zertifikat passt zu einer anderen Domain oder Subdomain | Ob die Anfrage wirklich über den erwarteten Host läuft |
Ein Detail wird oft übersehen: Postman speichert Zertifikate lokal und nicht in der Cloud. Wenn ein Kollege denselben Endpoint problemlos anspricht, heißt das noch lange nicht, dass auf deinem Rechner dieselbe CA, dasselbe Client-Zertifikat oder derselbe Agent aktiv ist. Genau an dieser Stelle hilft ein sauberer, schrittweiser Fix mehr als jedes Rätselraten.
Als Nächstes zeige ich dir deshalb die Reihenfolge, die ich selbst in der Praxis benutze.
So behebst du das Problem direkt in Postman
Für die schnelle Eingrenzung arbeite ich immer von einfach nach belastbar. Die Postman-Dokumentation trennt dabei sauber zwischen dem Deaktivieren der SSL-Prüfung, dem Hinterlegen von CA-Zertifikaten und dem Einsatz von Client-Zertifikaten. Diese Reihenfolge ist sinnvoll, weil du so zuerst feststellst, ob die Verbindung grundsätzlich funktioniert, und danach die eigentliche Vertrauenskette reparierst.
- Teste den Request einmal mit deaktivierter SSL-Prüfung. In den Request-Settings kannst du die Zertifikatsprüfung für diesen Call ausschalten. Wenn der Request dann läuft, ist das ein starkes Indiz für ein Zertifikats- oder Trust-Problem, nicht für einen defekten Endpoint.
- Prüfe die globale Einstellung nur zur Diagnose. Die gleiche Option gibt es in den App-Settings auch global. Ich nutze das höchstens kurz zum Eingrenzen, nicht als Dauerlösung.
- Importiere die richtige CA statt des Serverzertifikats. Wenn du mit einer internen CA, einem Lab-Setup oder selbstsignierten Zertifikaten arbeitest, gehört in Postman meist die CA-Datei im PEM-Format hinein, nicht nur das Leaf-Zertifikat.
- Konfiguriere Client-Zertifikate nur bei mTLS. Wenn der Server Mutual TLS verlangt, brauchst du ein passendes Client-Zertifikat mit Hostzuordnung. Der Host muss exakt stimmen, der Port in der Regel ebenfalls; ohne Angabe nutzt Postman standardmäßig 443.
- Kontrolliere den Request im Postman Console. Dort sehe ich, welches Zertifikat wirklich gesendet wurde und ob Postman schon beim Aufbau der Verbindung scheitert. Das spart Zeit, weil die Oberfläche den Fehlertext oft nur grob zusammenfasst.
- Prüfe, ob du im Web-Client arbeitest. Wenn du Postman im Browser nutzt, muss der Desktop Agent laufen. Ohne ihn landen manche Zertifikats- und Netzwerkfunktionen in einer anderen Ausführungsumgebung als erwartet.
Wenn nach diesen Schritten der Request mit ausgeschalteter Prüfung funktioniert, ist die Ursache fast sicher klar: Die Kette ist nicht vertrauenswürdig oder nicht vollständig. Dann lohnt sich der nächste Blick auf die Frage, wann man SSL-Verifizierung überhaupt abschalten darf.
Wann du SSL-Verifizierung ausschalten darfst und wann nicht
Ich halte das Deaktivieren der Zertifikatsprüfung für ein Diagnosewerkzeug, nicht für eine Lösung. In lokalen Entwicklungsumgebungen, isolierten Sandboxen oder beim ersten Test einer internen API kann das pragmatisch sein. Du möchtest dann schnell sehen, ob überhaupt Antworten zurückkommen, und ob die App auf Netzwerkebene grundsätzlich funktioniert.
Für Produktionssysteme, geteilte Testumgebungen und alles, was echte Nutzerdaten verarbeitet, gilt das Gegenteil: Dort darf die Prüflogik nicht dauerhaft aus sein. Ohne Verifikation verliert der Client die Garantie, dass er wirklich mit dem erwarteten Server spricht. Genau in solchen Momenten werden Man-in-the-middle-Probleme und falsch terminierte Proxys unsichtbar.
Mein praktischer Maßstab: Wenn das Ausschalten der Prüfung den Fehler beseitigt, ist das nur der Beweis, dass du die Ursache eingegrenzt hast. Gelöst ist damit noch nichts. Danach muss entweder die Zertifikatskette sauber gemacht oder die CA korrekt vertrauenswürdig eingebunden werden.
Damit landet die eigentliche Arbeit oft nicht in Postman selbst, sondern auf Server-, Proxy- oder Infrastruktur-Ebene.
Wenn die Ursache auf Server- oder Proxy-Seite liegt
Der häufigste echte Fix ist nicht in der Client-Oberfläche, sondern am Ende der TLS-Kette. Der Server muss die vollständige Kette ausliefern, also das Leaf-Zertifikat plus die notwendigen Intermediate-Zertifikate. Das Root-Zertifikat wird dabei in der Regel nicht vom Server mitgeschickt, sondern muss bereits lokal vertrauenswürdig sein.
Ich prüfe in solchen Fällen zuerst den TLS-Terminationspunkt: Ist es der eigentliche Applikationsserver, ein Reverse Proxy, ein Ingress, ein Load Balancer oder ein CDN? Genau dort muss die Kette vollständig hinterlegt sein. In Nginx-, IIS- oder Cloud-Setups liegt der Fehler oft schlicht darin, dass nur das Endzertifikat installiert wurde und die Chain-Datei fehlt oder falsch zugeordnet ist.
Bei internen PKI-Umgebungen kommt noch ein zweiter Punkt dazu: Die Root-CA oder das Intermediate-Zertifikat muss dort bekannt sein, wo validiert wird. Auf dem Arbeitsplatzrechner kannst du die CA in Postman hinterlegen oder systemweit importieren. Wenn mehrere Tools und Teams betroffen sind, ist der saubere Weg meist der zentrale Trust Store, nicht das einzelne Workaround pro Anwendung.
Auch Proxys verdienen hier besondere Aufmerksamkeit. Ein Sicherheitsgateway, das TLS aufbricht und neu signiert, erzeugt eine andere Zertifikatskette als der eigentliche Zielserver. Dann hilft nur, die Proxy-CA korrekt zu verteilen oder die TLS-Inspection für diesen Zielbereich kontrolliert zu behandeln. Sonst bleibt die Fehlermeldung trotz scheinbar korrekter Serverkonfiguration bestehen.
Ein letzter realistischer Punkt: Zertifikate haben ein Ablaufdatum. Gerade bei automatisierten Setups mit kurzen Laufzeiten, etwa 90 Tagen, fallen fehlende Erneuerungen nicht sofort auf, sondern erst dann, wenn die Kette nicht mehr vollständig oder nicht mehr vertrauenswürdig ist. Deshalb gehört ein funktionierender Erneuerungsprozess genauso zur Lösung wie die Erstkonfiguration.
Wenn du diese Stellschrauben sauber trennst, wird aus einer vagen SSL-Meldung ein klarer Infrastrukturfehler, den man gezielt beheben kann.
Der schnellste Prüfpfad, wenn die Anfrage heute noch laufen muss
Wenn ich unter Zeitdruck bin, gehe ich immer dieselbe Reihenfolge durch: Erst prüfe ich im Postman Console, ob überhaupt ein Zertifikat gesendet wurde. Danach teste ich den Request einmal mit ausgeschalteter SSL-Prüfung, um das Problem einzugrenzen. Wenn der Call dann funktioniert, kommt die CA-Kette an die Reihe, nicht der Request selbst.
- Stimmt der Hostname exakt, inklusive Subdomain und Port?
- Wird der Endpoint über HTTPS angesprochen und nicht versehentlich über HTTP?
- Fehlt ein Intermediate-Zertifikat auf dem Server oder im Proxy?
- Ist bei mTLS wirklich das passende Client-Zertifikat hinterlegt?
- Arbeitest du im Web-Client und ist der Desktop Agent aktiv?
Wenn du diese fünf Punkte nacheinander abarbeitest, findest du die Ursache in den meisten Fällen schneller als über ständiges Neuladen oder blindes Ausschalten der Prüfung. Genau das ist der pragmatische Weg: erst verifizieren, dann korrigieren, dann die SSL-Prüfung wieder einschalten und den Request erneut sauber testen.
