Why HTTPS needs the CA#
The proxy signs an on-the-fly certificate for each hostname, so a client only accepts intercepted HTTPS once the GraphDagger CA is in its trust store.
HTTPS interception works only if you install and trust the GraphDagger CA certificate on the machine that generates the traffic. Without that certificate, browsers and tools refuse to connect, or warn loudly, on every HTTPS request.
The Certificates dialog lives at the bottom of the settings menu under the Certificates... entry. It walks through three states.
- Generating the CA: the first step on a new machine.
- Trusting the CA: add the CA to the system trust store so HTTPS interception works without warnings.
- Exporting and deleting the CA: install the CA on another device, or remove it.
Why the client must trust the CA#
When HTTPS interception is on, the proxy generates a certificate for each hostname and signs it with the GraphDagger CA. The proxy presents that certificate to the client. If the client trusts the CA, it accepts the certificate, and the proxy decrypts the traffic. If not, the client sees a CA mismatch, and it refuses or warns.
The proxy runs two TLS sessions: one with the client and one with the origin. It reads and modifies the traffic between them only because the client trusts the generated leaf certificate. The client trusts that certificate only if the GraphDagger CA is in its trust store.
When you do not need a CA#
If you turn HTTPS interception off in the settings menu, HTTPS connections pass through opaquely, and you never need to trust the CA. In that mode you cannot read or modify HTTPS bodies.
Where the CA lives#
GraphDagger stores the CA alongside the workspace data. If you generate, delete, or re-generate the CA, the captures already on disk stay the same. Only future HTTPS interception changes.