What Is a Burp Suite CA Certificate and Why Does It Matter?

If you've ever tried to intercept HTTPS traffic using Burp Suite, you've almost certainly hit a browser warning telling you the connection isn't trusted. That warning points directly to the Burp Suite CA certificate — a foundational piece of how the tool does its job. Understanding what it is, how it works, and what affects your setup makes the difference between a smooth testing session and a frustrating wall of security errors.

The Core Concept: What Is a CA Certificate?

A CA (Certificate Authority) certificate is a digital credential that vouches for the identity of other certificates. When your browser connects to an HTTPS site, it checks whether the site's certificate was signed by a trusted CA. If it was, the padlock appears. If it wasn't, you get a warning.

Burp Suite acts as a proxy — it sits between your browser and the internet, intercepting and inspecting encrypted traffic. To read HTTPS data (which is encrypted), Burp Suite performs what's called a man-in-the-middle (MITM) interception. It decrypts the traffic from the server, inspects it, then re-encrypts it for your browser using its own certificate.

That re-encrypted connection is signed by Burp Suite's own internal CA — the Burp Suite CA certificate. Since your browser doesn't recognize Burp as a trusted authority by default, it throws a warning.

Installing the Burp CA certificate into your browser or operating system tells your system: "This CA is trusted." After that, Burp can intercept HTTPS traffic without triggering security alerts.

How Burp Generates Its CA Certificate 🔐

Burp Suite generates a unique CA certificate the first time it runs on a machine. This means every installation has its own certificate — it's not a shared, publicly distributed credential. The certificate is stored locally in Burp's configuration directory.

From this root CA, Burp dynamically creates per-site certificates. When you visit https://example.com through Burp's proxy, Burp generates a certificate specifically for example.com, signed by its local CA. Your browser sees a valid-looking cert for that domain, signed by an authority it now trusts (because you installed the CA cert).

This is why the installation step matters so much: without it, every HTTPS site you visit through Burp triggers a browser warning, and in many modern browsers, the page will be blocked entirely.

Where to Install It — And Why That Varies

Where and how you install the Burp CA certificate depends heavily on your environment:

Firefox is notably different from Chrome and Edge — it maintains its own certificate store, so even if you've installed the cert system-wide on Windows or macOS, you may need to import it separately into Firefox through its preferences.

Android and iOS Add Complexity

Mobile testing introduces significant variables. On Android 7.0 and above, apps no longer trust user-installed CA certificates by default. This means even if you install Burp's cert as a user certificate, most apps will still refuse to connect through the proxy. Getting around this typically requires either:

• Rooting the device and moving the cert to the system store
• Using an emulator with root access
• Modifying the app's network security config (if you have access to the source)

On iOS, the process involves installing a profile and then separately enabling full trust under Settings > General > About > Certificate Trust Settings. Skipping the second step is one of the most common reasons the cert appears installed but still doesn't work.

What the Certificate Is NOT 🚫

It's worth being clear about what the Burp CA certificate is not:

• It is not a publicly trusted certificate — it only works for devices where you explicitly install and trust it
• It is not designed for production environments — installing it on live user devices would expose those users to potential interception
• It is not permanent by default — Burp's generated CA certificate has an expiration date; if it expires, you'll need to regenerate and reinstall it

The certificate is strictly a local testing tool. Its value is entirely in controlled environments — security research, penetration testing, bug bounty work, and application debugging.

The Variables That Shape Your Actual Experience

Several factors determine how smoothly this all works in practice:

• Your operating system — macOS, Windows, and Linux each have different trust store mechanisms
• Which browser you use — Firefox's independence from the OS store catches many users off guard
• Your target device — mobile testing, especially on newer Android versions, is considerably more involved than desktop testing
• Whether you're testing native apps or just web traffic — native apps may implement certificate pinning, which bypasses the system trust store entirely and requires additional techniques
• Your Burp Suite version — the location for downloading the CA cert and the cert's properties have changed across versions

Certificate pinning deserves special mention. Some apps hardcode the specific certificates they'll accept, meaning even a trusted CA won't help — the app will reject the connection regardless. This is a separate challenge from basic CA installation and requires different tooling to address.

The right approach to all of this shifts depending on what you're testing, what device you're working on, and how your target application handles certificate validation — which is where your specific setup becomes the determining factor.