Cybersecurity / Networking

Burp Suite Not Intercepting HTTPS Traffic

When Burp Suite intercepts plain HTTP traffic fine but HTTPS requests fail, hang, or simply never appear in the proxy history, it's almost always because the client (browser or app) doesn't trust Burp's certificate authority yet — HTTPS interception fundamentally depends on that trust being established first.

The Problem

HTTP requests show up in Burp's Proxy tab as expected, but HTTPS requests either fail with a certificate warning in the browser, time out, or simply never reach Burp's history at all — as if the traffic is bypassing the proxy entirely for anything secured.

Burp as a man-in-the-middle Browser Burp Suite (own cert) Real server Browser must trust Burp's CA cert, or the middle step breaks

Why It Happens

Burp intercepts HTTPS by presenting its own certificate to the client and separately connecting to the real server, effectively sitting in the middle of an otherwise encrypted connection. This only works if the client explicitly trusts Burp's certificate authority. Common causes of failure:

  • Burp's CA certificate was never installed in the browser or system's trust store, so every HTTPS connection through the proxy gets rejected as untrusted
  • The browser is using its own separate certificate store rather than the operating system's (Firefox does this by default), so installing the certificate system-wide doesn't cover it
  • The proxy listener in Burp isn't actually configured to intercept the port or interface the browser is sending traffic through
  • The target application uses certificate pinning, which explicitly rejects any certificate other than the one it expects — deliberately defeating exactly this kind of interception as a security measure

The Fix

First, confirm Burp's proxy listener is active and configured correctly: Proxy tab > Options > Proxy Listeners, confirm 127.0.0.1:8080 (or your configured port) is running.

Install Burp's CA certificate in your browser or system. With the browser configured to use Burp's proxy, visit:

http://burp

This serves Burp's CA certificate directly. Download it and install it as a trusted root certificate authority — the exact steps depend on your OS/browser, but the general path is: Settings > Certificates > Import > mark as trusted for identifying websites.

If you're using Firefox specifically, remember it maintains its own certificate store separate from the OS: Firefox Settings > Privacy & Security > Certificates > View Certificates > Import, and select the downloaded Burp CA certificate there as well.

Confirm your browser or system proxy settings actually point to Burp's listener address and port, since HTTPS traffic bypassing the configured proxy entirely produces the same symptom as a certificate trust issue, but for a completely different reason.

If you're testing a mobile app rather than a browser, install the certificate on the device itself (as a user or system certificate, depending on Android version), and configure the device's Wi-Fi proxy settings to route through Burp running on your machine.

Still Not Working?

If the certificate is correctly installed and trusted, but a specific application still fails, it likely uses certificate pinning — hardcoding which exact certificate (or public key) it will accept, regardless of what the system trust store says. In that case, Burp's own documentation and mobile-specific tools like Frida or objection are typically needed to bypass pinning at the application level, since installing a trusted CA certificate alone can't defeat pinning that checks the certificate's specific fingerprint rather than just trust chain validity.

It's also worth checking whether the target uses HSTS (HTTP Strict Transport Security), which can cause the browser to refuse the connection outright if it detects anything unusual about the certificate chain, even before Burp's certificate warning would normally appear. Once a browser has cached an HSTS policy for a domain, it can be more aggressive about rejecting certificate mismatches than it would be for a domain visited for the first time — clearing the browser's HSTS cache for that specific domain (found in most browsers' internal network settings pages) removes this as a variable while testing.

Finally, confirm you're testing against the actual proxy port Burp is listening on, and that no other proxy tool or VPN client is also intercepting traffic simultaneously. Running two interception tools at once — for example, a system-wide VPN alongside Burp's proxy — can create conflicting TLS handling that produces symptoms very similar to a missing certificate, even when Burp itself is configured correctly.

You might also like