Zertifikat Installieren: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Wer HTTPS-Traffic mit Burp Suite analysieren will, muss verstehen, was beim TLS-Handshake tatsächlich passiert. Ein Browser oder eine App erwartet vom Zielserver ein Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde. Burp arbeitet als Man-in-the-Middle-Proxy im legitimen Testkontext: Die Anwendung baut die Verbindung zu Burp auf, Burp baut eine zweite Verbindung zum eigentlichen Ziel auf und erzeugt für die Ziel-Domain dynamisch ein eigenes Zertifikat. Damit der Client dieses Zertifikat akzeptiert, muss die Burp-CA im jeweiligen Trust-Store als vertrauenswürdig installiert sein.

Ohne diesen Schritt scheitert HTTPS-Intercept fast immer mit Warnungen wie „Your connection is not private“, „SEC_ERROR_UNKNOWN_ISSUER“, „NET::ERR_CERT_AUTHORITY_INVALID“ oder generischen TLS-Fehlern in mobilen Apps. Viele Einsteiger interpretieren das als Proxy- oder Netzwerkproblem. Tatsächlich ist es meist kein Routing-Fehler, sondern ein Vertrauensproblem zwischen Client und Burp-CA.

Wichtig ist die Trennung zwischen drei Ebenen: Netzwerkpfad, Proxy-Konfiguration und Zertifikatsvertrauen. Wenn der Browser Burp nicht erreicht, liegt das Problem oft bei Listener, Host, Port oder System-Proxy. Wenn Burp erreicht wird, aber HTTPS scheitert, liegt das Problem meist beim Zertifikat. Wenn einzelne Apps trotz korrekt installiertem Zertifikat nicht funktionieren, greifen oft Certificate Pinning, eigener App-Trust-Store oder restriktive Mobile-Security-Policies. Für die Grundlagen zu Listenern und Routing ist Proxy Einrichten die passende Ergänzung, während für den Gesamtüberblick Anleitung und Proxy Https den technischen Rahmen liefern.

Das Burp-Zertifikat ist also kein optionales Extra, sondern die Voraussetzung dafür, verschlüsselten Traffic sauber zu inspizieren, zu verändern und reproduzierbar zu testen. Ohne korrektes Vertrauen bleibt Burp bei HTTPS weitgehend blind. Gerade bei Login-Flows, Session-Handling, API-Requests und Single-Page-Anwendungen ist das ein Showstopper, weil fast alle relevanten Daten heute ausschließlich über TLS übertragen werden.

Ein häufiger Fehler in der Praxis ist die Annahme, dass „Zertifikat installiert“ überall dasselbe bedeutet. Das ist falsch. Je nach Plattform wird Vertrauen an unterschiedlichen Stellen verwaltet. Manche Browser nutzen den System-Trust-Store, andere bringen eigene Mechanismen mit. Mobile Apps können zusätzlich eigene Zertifikatsspeicher oder Pinning-Logik verwenden. Deshalb funktioniert Burp manchmal im Browser, aber nicht in der nativen App auf demselben Gerät.

Unter Windows greifen viele Anwendungen auf den Zertifikatsspeicher des Betriebssystems zu. Unter macOS ist die Schlüsselbundverwaltung relevant. Unter Linux hängt es stark von Distribution, Browser und Laufzeitumgebung ab. Firefox kann je nach Konfiguration eigene Zertifikatsmechanismen nutzen. Android unterscheidet zwischen Benutzerzertifikaten und Systemzertifikaten, und seit Android 7 vertrauen viele Apps Benutzer-CAs standardmäßig nicht mehr. iOS akzeptiert ein installiertes Root-Zertifikat erst dann vollständig, wenn es zusätzlich explizit als vertrauenswürdig aktiviert wurde.

Für saubere Fehlersuche hilft ein klares Modell:

• System-Trust-Store: relevant für viele Desktop-Anwendungen und einige Browser.
• Browser-spezifischer Trust-Store: relevant, wenn ein Browser Zertifikate separat verwaltet oder eigene Policies anwendet.
• App-spezifischer Trust-Store oder Pinning: relevant bei mobilen Apps, Electron-Anwendungen, Java-Clients oder sicherheitsgehärteten Programmen.

Diese Trennung erklärt, warum ein Zertifikat auf dem Host korrekt installiert sein kann, während eine Zielanwendung trotzdem TLS ablehnt. In Pentests spart dieses Verständnis viel Zeit, weil die Analyse nicht blind auf Burp oder das Netzwerk geschoben wird. Stattdessen wird gezielt geprüft, welche Komponente das Vertrauen verweigert. Für tiefergehende Fehlerbilder ist Zertifikat Fehler sinnvoll, und bei generellen Problemen mit dem Setup hilft Funktioniert Nicht.

Ein weiterer Punkt: Das Burp-Zertifikat ist eine Root-CA für die lokale Testumgebung. Es wird nicht das echte Serverzertifikat importiert, sondern die lokale Zertifizierungsstelle, mit der Burp für jede Ziel-Domain ein passendes Leaf-Zertifikat generiert. Genau deshalb muss die Root-CA vertrauenswürdig sein. Wer stattdessen versucht, einzelne Zielzertifikate zu importieren, arbeitet am Problem vorbei.

Der robusteste Weg beginnt immer mit einem funktionierenden Proxy-Listener. Standardmäßig lauscht Burp oft auf 127.0.0.1:8080. Der Browser muss diesen Proxy aktiv verwenden. Erst wenn HTTP-Anfragen sichtbar in Burp ankommen, lohnt sich der Zertifikatsschritt. Danach wird im Browser die URL http://burp aufgerufen. Dort stellt Burp die eigene CA zum Download bereit. Diese CA wird exportiert und anschließend im passenden Zertifikatsspeicher importiert.

Im Desktop-Kontext ist die Reihenfolge entscheidend. Zuerst Listener prüfen, dann Proxy im Client setzen, dann CA herunterladen, dann importieren, dann Browser oder Anwendung neu starten und erst danach HTTPS testen. Viele Fehler entstehen, weil Zertifikate importiert werden, bevor klar ist, ob der Traffic überhaupt durch Burp läuft. Dann werden zwei Probleme gleichzeitig vermischt.

Ein typischer Ablauf sieht so aus:

1. Burp starten
2. Proxy Listener prüfen, z. B. 127.0.0.1:8080
3. Browser-Proxy auf 127.0.0.1 Port 8080 setzen
4. http://burp aufrufen
5. CA-Zertifikat herunterladen
6. Zertifikat als vertrauenswürdige Root-CA importieren
7. Browser neu starten
8. HTTPS-Ziel aufrufen und Intercept testen

Wenn nach dem Import weiterhin Zertifikatswarnungen erscheinen, muss geprüft werden, ob das Zertifikat wirklich als Root-CA und nicht nur als normales Zertifikat importiert wurde. Ebenso wichtig ist die Frage, ob der richtige Store verwendet wurde. Ein Import in „Persönlich“ statt „Vertrauenswürdige Stammzertifizierungsstellen“ bringt unter Windows beispielsweise nicht das gewünschte Ergebnis. Unter macOS muss im Schlüsselbund die Vertrauenseinstellung korrekt gesetzt werden. Unter Linux hängt die konkrete Vorgehensweise von Browser und Distribution ab; bei Firefox ist oft der Zertifikatsspeicher des Browsers selbst relevant.

Wer Burp gerade erst aufsetzt, sollte zuerst Installation, Erste Schritte und Proxy sauber durchgehen. Das reduziert Folgefehler, weil Listener, Intercept und Zertifikatsvertrauen dann in einer logischen Reihenfolge eingerichtet werden.

Unter Windows ist der häufigste saubere Weg der Import der Burp-CA in den Zertifikatsspeicher des aktuellen Benutzers oder des lokalen Computers unter „Trusted Root Certification Authorities“. Für Browser, die den Windows-Store nutzen, reicht das oft aus. Wenn ein Browser weiterhin meckert, muss geprüft werden, ob er einen eigenen Store nutzt oder ob Gruppenrichtlinien den Import blockieren. In Unternehmensumgebungen können Endpoint-Security-Produkte zusätzlich TLS-Inspection oder Zertifikatsrichtlinien erzwingen, was zu schwer nachvollziehbaren Konflikten führt.

Unter macOS wird die CA typischerweise in den Schlüsselbund importiert. Entscheidend ist nicht nur der Import selbst, sondern die Vertrauenseinstellung. Ein Zertifikat im Schlüsselbund zu haben bedeutet noch nicht automatisch, dass es für SSL immer vertraut wird. Wenn Burp zwar erreichbar ist, Safari oder Chrome aber weiter warnen, liegt die Ursache oft genau dort. Nach Änderungen am Schlüsselbund kann ein Neustart des Browsers oder in manchen Fällen des Systems nötig sein.

Unter Linux ist die Lage heterogener. Chromium-basierte Browser können je nach Distribution und Build andere Trust-Mechanismen nutzen als Firefox. Systemweite CA-Updates über Distributionstools wirken nicht immer auf alle Anwendungen. In Pentest-VMs wird deshalb oft pragmatisch direkt im Browser importiert, um die Fehlerfläche klein zu halten. Das ist nicht immer die eleganteste, aber oft die schnellste Methode für reproduzierbare Testumgebungen. Wer Burp in einer dedizierten VM betreibt, sollte die CA nur dort vertrauen und nicht unnötig systemweit auf dem Host verteilen.

Für plattformspezifische Setups sind Windows Installation, Mac Installation und Kali Linux Linux die passenden Vertiefungen. In der Praxis ist es sinnvoll, pro Betriebssystem eine kurze Checkliste zu pflegen: Wo liegt der Trust-Store, welcher Browser wird verwendet, welche Neustarts sind nötig und welche Sicherheitssoftware könnte eingreifen.

Ein häufiger Profi-Fehler ist übrigens nicht die technische Installation, sondern das Vermischen von Testumgebungen. Wenn Burp auf dem Host läuft, der Browser aber in einer VM, muss das Zertifikat in der VM installiert werden, nicht auf dem Host. Dasselbe gilt für Remote-Geräte, Container-Umgebungen und Emulatoren. Vertrauen ist immer lokal zur Komponente, die die TLS-Verbindung validiert.

Auf mobilen Geräten ist das Thema deutlich anspruchsvoller als im Desktop-Browser. Zuerst muss das Gerät den Burp-Proxy erreichen. Das bedeutet meist: Burp lauscht nicht nur auf 127.0.0.1, sondern auf einem Interface, das im lokalen Netz erreichbar ist, und die Firewall lässt den Port zu. Danach wird auf dem Gerät ein WLAN-Proxy gesetzt, der auf die IP des Burp-Hosts zeigt. Erst wenn HTTP-Traffic sichtbar ist, lohnt sich der Zertifikatsimport.

Bei Android wird das Burp-Zertifikat häufig als Benutzerzertifikat installiert. Das reicht für Browser-Tests oft aus, aber nicht zwingend für Apps. Seit Android 7 vertrauen viele Apps Benutzer-CAs nicht automatisch. Wenn eine App zusätzlich Certificate Pinning verwendet, scheitert Interception selbst dann, wenn die CA korrekt installiert ist. Dann liegt kein Installationsfehler vor, sondern eine bewusste Sicherheitsmaßnahme der App. In solchen Fällen sind weitergehende Techniken nötig, etwa Instrumentierung, Frida-basierte Pinning-Bypässe oder modifizierte Testumgebungen. Diese Schritte gehören jedoch in einen kontrollierten, autorisierten Mobile-Pentest und nicht in ein Standard-Setup.

Bei iOS wird das Profil mit dem Zertifikat installiert, danach muss das Root-Zertifikat in den Einstellungen explizit als vertrauenswürdig aktiviert werden. Dieser zweite Schritt wird extrem oft vergessen. Das Ergebnis ist ein scheinbar korrekt installiertes Zertifikat, das aber praktisch nicht genutzt wird. Auch hier gilt: Browser kann funktionieren, einzelne Apps nicht. Ursache sind dann meist App-spezifische Validierung, ATS-Richtlinien oder Pinning.

In Emulatoren und Simulatoren ist die Lage oft angenehmer, weil Snapshots, Root-Zugriff und reproduzierbare Zustände möglich sind. Für ernsthafte mobile Analysen lohnt sich eine dedizierte Testumgebung mit dokumentierter Proxy-IP, Listener-Port, Zertifikatsversion und App-Build. Sonst wird Fehlersuche schnell chaotisch, besonders wenn mehrere Geräte parallel verwendet werden.

• Erst Netzwerkpfad prüfen: erreicht das Gerät den Burp-Listener überhaupt.
• Dann Proxy testen: kommt unverschlüsselter Traffic in Burp an.
• Danach Zertifikat importieren und Vertrauen aktivieren.
• Wenn nur einzelne Apps scheitern, an Pinning oder App-Policies denken.

Für die operative Arbeit mit Requests nach erfolgreicher Interception sind Proxy Intercept und Repeater die nächsten logischen Werkzeuge.

In der Praxis wiederholen sich dieselben Fehler. Der Unterschied zwischen Anfängern und erfahrenen Testern liegt weniger darin, ob Fehler auftreten, sondern wie schnell sie systematisch eingegrenzt werden. Statt wahllos Einstellungen zu ändern, wird die Kette vom Client bis zum Ziel in klaren Schritten geprüft.

Das häufigste Muster ist: HTTP funktioniert, HTTPS nicht. Dann ist der Proxy-Pfad grundsätzlich in Ordnung, aber das Zertifikatsvertrauen fehlt oder ist falsch gesetzt. Wenn weder HTTP noch HTTPS funktioniert, ist zuerst der Listener, die Proxy-Konfiguration oder die Erreichbarkeit zu prüfen. Wenn Browser funktioniert, App aber nicht, ist der Trust-Store oder Pinning der App der wahrscheinlichste Kandidat.

Einige typische Symptome und ihre wahrscheinlichen Ursachen:

Symptom: Browser zeigt Zertifikatswarnung
Wahrscheinliche Ursache: Burp-CA nicht oder falsch importiert

Symptom: HTTP geht, HTTPS hängt oder bricht ab
Wahrscheinliche Ursache: TLS-Vertrauen fehlt, falscher Zertifikatsspeicher

Symptom: Browser geht, mobile App nicht
Wahrscheinliche Ursache: App vertraut Benutzer-CA nicht oder nutzt Pinning

Symptom: Gar kein Traffic in Burp
Wahrscheinliche Ursache: Proxy nicht gesetzt, falscher Listener, Firewall, falsche IP

Symptom: Nur manche Domains schlagen fehl
Wahrscheinliche Ursache: HSTS, Pinning, SNI-/TLS-Besonderheiten, Upstream-Proxy-Konflikte

Ein weiterer Klassiker ist der Import einer alten Burp-CA nach Neuinstallation oder Projektwechsel. Wenn Burp eine neue CA erzeugt hat, vertraut der Client weiterhin der alten Root-CA, nicht der aktuellen. Das führt zu schwer erkennbaren Fehlern, weil „doch schon mal alles funktioniert hat“. In Teamumgebungen ist das besonders relevant, wenn mehrere Burp-Instanzen oder gemeinsam genutzte Testgeräte im Umlauf sind.

Ebenso problematisch sind parallele TLS-inspektierende Komponenten: Unternehmensproxy, Antivirus mit HTTPS-Scanning, lokale Security-Suiten oder Browser-Erweiterungen. Dann konkurrieren mehrere Zertifikatsketten miteinander. Burp ist nicht mehr der einzige MITM im Pfad, und die resultierenden Fehler wirken zufällig. In solchen Fällen muss die Kette vereinfacht werden: unnötige TLS-Inspection deaktivieren, dedizierte Test-VM nutzen oder Burp in einer isolierten Umgebung betreiben.

Für konkrete Störungsbilder sind Proxy Fehler, Proxy Verbindungsfehler und Debugging die passenden Vertiefungen.

Ein stabiler Workflow verhindert, dass Zertifikatsprobleme mitten in einer Analyse eskalieren. In professionellen Assessments wird das Setup nicht improvisiert, sondern standardisiert. Dazu gehört eine definierte Burp-Version, dokumentierte Listener-Konfiguration, klarer Umgang mit Zertifikaten und eine getrennte Testumgebung pro Kunde oder Projekt.

Ein bewährter Ablauf beginnt mit einer frischen Projektdatei und einer kurzen Funktionsprüfung gegen ein bekanntes HTTPS-Ziel. Erst wenn Interception dort sauber funktioniert, wird die eigentliche Zielanwendung eingebunden. So lässt sich unterscheiden, ob ein Problem am Burp-Setup oder an der Zielanwendung liegt. Danach werden Scope, Logging und Proxy-Historie vorbereitet, damit Requests nachvollziehbar bleiben. Für diese operative Struktur sind Workflow, Proxy History und Scope direkt relevant.

In realen Web-Pentests ist das Zertifikat nicht nur ein Installationsdetail, sondern die Grundlage für fast alle Folgeaktivitäten. Ohne funktionierende HTTPS-Interception sind Session-Cookies, CSRF-Tokens, JWTs, API-Requests und Login-Flows nur eingeschränkt analysierbar. Das betrifft praktisch alle Kernaufgaben im Web Pentest.

Ein sauberer Workflow umfasst typischerweise:

• Dedizierte Testumgebung statt produktiv genutztem Alltagsbrowser.
• Dokumentierte Burp-CA pro Umgebung und kontrollierter Zertifikatsimport.
• Kurzer HTTPS-Selbsttest vor Beginn jeder Session.
• Klare Trennung zwischen Browser-Tests, API-Clients und mobilen Geräten.
• Entfernung nicht mehr benötigter Burp-CAs nach Abschluss des Projekts.

Gerade der letzte Punkt wird oft vernachlässigt. Eine lokal vertraute Test-CA sollte nicht dauerhaft auf produktiv genutzten Systemen verbleiben. Auch wenn das Risiko im kontrollierten Umfeld begrenzt ist, widerspricht es sauberer Betriebshygiene. In professionellen Umgebungen werden Test-VMs nach Abschluss zurückgesetzt oder Zertifikate gezielt entfernt.

Wer mit mehreren Tools arbeitet, sollte außerdem vermeiden, dass Browser, API-Clients und mobile Geräte gleichzeitig auf unterschiedliche Proxys zeigen. Inkonsistente Proxy-Ketten erzeugen schwer reproduzierbare Fehler. Besser ist ein klarer, einfacher Pfad: Client zu Burp, Burp zu Ziel. Erst wenn dieser Pfad stabil ist, werden Erweiterungen, Upstream-Proxys oder Automatisierung ergänzt.

Viele Setups wirken auf den ersten Blick funktionsfähig, sind aber nur teilweise korrekt. Ein Browser lädt vielleicht eine Seite, während Hintergrund-Requests fehlschlagen. Oder Intercept funktioniert für einfache GET-Requests, aber WebSockets, API-Calls oder Redirect-Ketten verhalten sich auffällig. Deshalb sollte die Zertifikatsinstallation immer aktiv verifiziert werden.

Die erste Prüfung ist simpel: Eine HTTPS-Seite aufrufen und im Browser das präsentierte Zertifikat ansehen. Wenn Burp korrekt dazwischen sitzt, stammt das Leaf-Zertifikat nicht direkt vom Originalserver, sondern wurde von der Burp-CA ausgestellt. Danach wird in Burp kontrolliert, ob Request und Response vollständig sichtbar sind. Anschließend sollte ein Request gezielt modifiziert werden, etwa ein Header oder Parameter. Wenn die Änderung am Ziel ankommt, ist nicht nur das Vertrauen korrekt, sondern die gesamte Interception-Kette funktionsfähig.

Ein sinnvoller Minimaltest sieht so aus:

GET / HTTP/1.1
Host: example.org
User-Agent: Test-Agent
X-Burp-Validation: active

Wird dieser Request in Burp sichtbar, kann verändert und erfolgreich weitergeleitet werden, ist das Setup grundsätzlich einsatzbereit. Danach lohnt sich ein Test mit Authentifizierung, Cookies und Redirects. Gerade Session-Handling deckt schnell auf, ob einzelne Requests am Proxy vorbeigehen oder ob Browser und App unterschiedliche Netzwerkpfade nutzen.

Für die Verifikation im Alltag sind folgende Punkte entscheidend: Zertifikatskette im Client prüfen, Burp-Historie kontrollieren, Request aktiv verändern, Response vergleichen und bei Bedarf denselben Request in Repeater Anleitung nachstellen. Wenn ein Verhalten nur im Browser, aber nicht im Repeater auftritt, liegt die Ursache oft nicht am Zertifikat, sondern an Client-seitiger Logik, Caching, CSP, JavaScript oder Session-Zustand.

Auch Performance ist ein Indikator. Wenn nach Zertifikatsinstallation jede HTTPS-Anfrage ungewöhnlich langsam wird, können DNS-Probleme, Upstream-Proxys, TLS-Inspection durch Drittsysteme oder überladene Burp-Extensions die Ursache sein. Dann lohnt ein Blick auf Performance und gegebenenfalls auf installierte Extensions.

Das Installieren einer lokalen Root-CA ist technisch notwendig, aber sicherheitlich sensibel. Eine Root-CA, der das System vertraut, kann Zertifikate für beliebige Hosts ausstellen, die vom Client akzeptiert werden. In der Testumgebung ist das gewollt. Außerhalb davon ist es ein Risiko. Deshalb gehört zum professionellen Umgang mit Burp nicht nur die Installation, sondern auch die kontrollierte Entfernung und die Begrenzung des Vertrauensbereichs.

Die Burp-CA sollte nur auf Systemen installiert werden, die tatsächlich für Tests genutzt werden. Ein produktiv genutzter Arbeitsbrowser mit dauerhaft importierter Test-CA ist schlechte Praxis. Besser sind dedizierte Browser-Profile, isolierte VMs oder separate Geräte. So bleibt die Vertrauensausweitung auf den vorgesehenen Kontext beschränkt. Wer regelmäßig Assessments durchführt, profitiert stark von Snapshots oder Infrastructure-as-Code für Testumgebungen, weil Zertifikate dadurch reproduzierbar und rückstandsfrei verwaltet werden können.

Ebenso wichtig ist die Herkunft des Zertifikats. Installiert wird ausschließlich die CA aus der eigenen Burp-Instanz, idealerweise direkt über http://burp im kontrollierten Setup. Zertifikatsdateien aus alten Projekten, fremden Archiven oder Team-Chats sind unnötige Fehlerquellen. Wenn mehrere Tester zusammenarbeiten, sollte klar dokumentiert sein, welche Burp-Instanz welche CA verwendet und auf welchen Geräten sie importiert wurde.

Aus rechtlicher und organisatorischer Sicht gilt zusätzlich: TLS-Interception darf nur in autorisierten Testkontexten erfolgen. Das betrifft besonders mobile Geräte, Unternehmensnetzwerke und Anwendungen mit echten Benutzerdaten. Für den Rahmen solcher Arbeiten sind Legal und Ethisches Hacking relevant.

Nach Projektende sollte mindestens geprüft werden, ob die Burp-CA noch benötigt wird. In vielen Fällen ist die beste Lösung, die Testumgebung zurückzusetzen. Wo das nicht möglich ist, wird die CA gezielt entfernt und der Proxy deaktiviert. Das verhindert spätere Verwirrung, wenn Monate später plötzlich Zertifikatswarnungen, Proxy-Reste oder unerwartete Routing-Probleme auftreten.

Wenn das Zertifikat korrekt installiert ist, beginnt erst die eigentliche Arbeit. Dann lassen sich Requests nicht nur sehen, sondern gezielt manipulieren, wiederholen und korrelieren. Das ist die Grundlage für Parameteranalysen, Session-Tests, Authentifizierungsprüfungen und API-Untersuchungen. Ohne stabile HTTPS-Interception bleiben viele dieser Schritte unzuverlässig oder vollständig blockiert.

Der nächste sinnvolle Schritt ist fast immer das Zusammenspiel aus Proxy und Repeater. Ein Request wird im Browser oder in der App erzeugt, in Burp abgefangen, dann an Repeater gesendet und dort systematisch verändert. So lassen sich Header, Cookies, JSON-Body, Query-Parameter und Autorisierungstoken kontrolliert testen. Für API-nahe Ziele ist API Testing besonders relevant, für Sitzungslogik Session Management und Cookies.

Auch bei typischen Schwachstellen ist das Zertifikat die Eintrittskarte in die Analyse. XSS, SQL Injection, IDOR, SSRF oder Login-Bypass lassen sich nur dann effizient prüfen, wenn Requests und Responses vollständig sichtbar sind. Das gilt besonders für moderne Anwendungen mit JSON, GraphQL, asynchronen Calls und komplexen Auth-Flows. Wer Burp nur als passiven Viewer nutzt, verschenkt Potenzial. Erst die Kombination aus sauberem Zertifikatssetup, Intercept, Repeater und strukturiertem Workflow macht das Werkzeug im Alltag wirklich stark.

Ein praxistauglicher Abschlusscheck vor jeder tieferen Analyse lautet daher: Läuft der Traffic sicher durch Burp, ist die Burp-CA im richtigen Trust-Store, lassen sich HTTPS-Requests ohne Warnungen abfangen und modifizieren, und ist klar, welche Clients dem Zertifikat tatsächlich vertrauen. Wenn diese Fragen sauber beantwortet sind, steht einer belastbaren Analyse nichts im Weg.