You point your app at an HTTPS API, the request goes through, and Rockxy shows a row for it. But the row is a dead end: a CONNECT line to api.example.com:443, no method, no headers, no body — just a tunnel. You can see that a connection happened and where it went, but the actual request and response are still encrypted.
That is the expected state before the proxy is trusted. The outcome of this guide is a decrypted row instead of a tunnel: after you install and trust Rockxy's root certificate and add the host to the SSL Proxying scope, the same request shows a readable method, URL, headers, request body, and response body. This is a one-time trust step per machine, plus a per-host decision about which traffic you actually want to open.
Why a tunnel row is not a decrypted row
HTTPS is built to stop a third party from reading traffic in transit — which is exactly what a debugging proxy is. When your client opens a TLS connection, it checks that the server's certificate chains back to a Certificate Authority the operating system already trusts. If nothing in that chain is trusted, the handshake is rejected.
To read the bytes, Rockxy has to sit in the middle: terminate the TLS connection from your client, decrypt, let you inspect, then open a second TLS connection to the real server. To terminate the client side, Rockxy must present a certificate your client will accept. It does not have the real server's private key, so it mints its own — a per-host leaf certificate with the correct hostname, signed by a root CA that Rockxy generated locally on your Mac.
That is the whole reason the trust step exists. Your client will only accept those minted per-host certificates if it trusts the root they chain back to. Until you tell macOS to trust Rockxy's root CA, every interception attempt would be a certificate error — so before you trust anything, the proxy leaves the connection as a pass-through tunnel and shows you the CONNECT row. Installing the root is what turns those tunnels into readable transactions. For a line-by-line account of how the interception and per-host signing work, see How Rockxy Intercepts HTTPS Without Compromising Security.
What you will need
- Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
- An administrator password. Adding a trusted root to the system Keychain is a privileged change, and macOS will ask for it once.
- A host whose HTTPS traffic you are authorized to inspect — an API you own, a staging service, or an app you are building. Trusting the proxy does not give you a right to decrypt other people's traffic.
- Optional: a terminal, if you want to confirm the trust with a single explicit request before pointing a whole app at the proxy.
Step 1 — Install and trust the root CA in the Keychain
Open Rockxy and go to its certificate trust setup. Rockxy generates a root Certificate Authority the first time it needs one and stores the private key in the macOS Keychain rather than as a file on disk. What you are trusting is that root, not any single site certificate.
When you start the install, macOS shows its own trust dialog and asks for your administrator password. This prompt comes from the system, not from Rockxy — the app cannot add a trusted root silently, and that is the correct boundary. Approve it once, and the root CA is marked trusted for SSL in the system Keychain. From that point on, any per-host leaf certificate Rockxy signs under that root will be accepted by clients that use the system trust store.
The exact button labels and dialog wording can shift between macOS and app versions, so follow the in-app prompt and the standard macOS "trust the root CA in Keychain Access" flow rather than memorizing a fixed click path. The current, screen-by-screen steps live in the certificates and trust docs.
Step 2 — Add the host to the SSL Proxying scope
Trusting the root is necessary but not sufficient. Rockxy does not decrypt every HTTPS connection just because it can — it decrypts the hosts you put in the SSL Proxying scope. Everything outside that scope is left as a plain tunnel, so unrelated traffic (system services, other apps) is not opened.
Add the host you want to inspect — for example api.example.com — to the SSL Proxying list. This is a deliberate two-part model: the root CA decides whether Rockxy is allowed to mint a trusted certificate at all, and the scope decides which hosts it actually does that for. Keeping the scope tight also keeps the traffic list readable, since you only decrypt what you are debugging.
Step 3 — Confirm trust with one request
Before wiring a whole application through the proxy, prove the trust works with a single request you control. Point one client at Rockxy's proxy port and hit a host that is inside the SSL Proxying scope. With curl, the proxy port goes in -x (read the active port from Rockxy's toolbar; the example assumes 8888):
curl -x http://127.0.0.1:8888 https://api.example.com/healthBecause the root is trusted, curl accepts the per-host certificate Rockxy presents, and the handshake succeeds instead of erroring. If you would rather test in the browser, load any HTTPS page for a host in scope; a trusted setup shows no certificate warning.
What you should see in Rockxy: a row for api.example.com that is no longer a bare tunnel. Selecting it shows the request method and URL, the request and response headers, and — the real proof — a readable response body rather than a CONNECT line with nothing under it. The screenshot below shows that decrypted shape.
That is the baseline. With one host decrypting cleanly, you can widen the scope to the rest of the API you are debugging and trust that the same trust chain is doing the work.
Runtimes that ignore the system Keychain
Trusting the root in the Keychain covers everything that uses the macOS system trust store — Safari, most native apps, curl, and many libraries. Some runtimes deliberately do not. Language runtimes and HTTP libraries often ship their own CA bundle and validate against that file instead of the system store, so they will keep rejecting Rockxy's certificate even after the Keychain trust is in place.
For those, the concept is the same but the target is different: the runtime needs Rockxy's root as a PEM in the trust store it reads. Export the root certificate as a PEM and point the runtime at it — typically an environment variable or config option that names a CA bundle path. The environment-specific setups (which variable, which file) are covered in the framework guides; the certificates and trust docs cover the export and the per-runtime pointers. The rule to remember: system Keychain trust and per-runtime CA-bundle trust are two separate stores, and a runtime that uses its own bundle needs the PEM added there explicitly.
If it does not work
The row is still a tunnel. Either the host is not in the SSL Proxying scope, or the client never sent the request through the proxy. Confirm the host is in scope, and confirm the client is actually using Rockxy's current toolbar port. Decryption only happens for in-scope hosts that reach the proxy.
A certificate error appears even though you trusted the root. The client is probably one that uses its own trust store, not the system Keychain. Export the root as a PEM and add it to that runtime's CA bundle, as above. This is the single most common reason a "trusted" setup still fails for one specific tool.
The host is localhost or 127.0.0.1 and no row appears at all. That is a routing problem, not a trust problem — loopback traffic skips the proxy by default. Route the client explicitly first, then apply the same trust and SSL-scope steps for the HTTPS case. The routing fix is in Why Localhost Traffic Isn't Showing in Your Proxy on macOS.
The handshake fails and the row is marked failed. The host almost certainly pins its certificate — more on that next. This is a real result about the host, not a misconfiguration on your side.
What trust does not buy you: certificate pinning
Installing and trusting the root does not defeat certificate pinning, and it is important to be plain about that. A pinned client hardcodes the exact certificate — or its public key hash — it expects from the server, and rejects anything else, including a certificate signed by a root you trust locally. Banking apps, payment SDKs, and some Apple system services pin on purpose, specifically to stop interception.
When a pinned connection reaches Rockxy, the TLS handshake fails on the client side, and Rockxy does not silently paper over it. The transaction is surfaced in the request list as a failed transaction — you see that the host was contacted and that the handshake did not complete, but there is no decrypted body, because there is none. Rockxy will not pretend to have decrypted something it could not. A proxy cannot bypass pinning without modifying the client application itself, and Rockxy does not go there. If a pinned host is one you do not need to inspect, leave it out of the SSL Proxying scope so it passes straight through as an encrypted tunnel.
Limitations to keep in mind
- Inspect only what you own or are authorized to. Trusting the root lets Rockxy decrypt in-scope HTTPS; it does not grant any right to decrypt traffic that is not yours to inspect. Keep the SSL Proxying scope pointed at your own hosts.
- Pinning is not bypassed. Pinned or otherwise failed handshakes appear as failed transactions, never as silently decrypted rows.
- Some runtimes need an explicit CA bundle. System Keychain trust does not reach runtimes that validate against their own bundle; those need the exported PEM added separately.
- macOS 14+ only. Rockxy is a native macOS app and requires Sonoma or later.
Next steps
The trust model is two decisions, not one: install and trust the root CA once so Rockxy is allowed to present certificates your clients accept, then add each host you care about to the SSL Proxying scope so it actually gets decrypted. A tunnel row becomes a full transaction, and the hosts you did not scope stay closed.
From here, put the decrypted traffic to work with the end-to-end setup in How to Debug HTTPS Traffic on macOS with a Local Proxy, read the internals in How Rockxy Intercepts HTTPS Without Compromising Security, or sort out routing first if your target is local with Why Localhost Traffic Isn't Showing in Your Proxy on macOS. The exact certificate steps stay current in the certificates and trust docs.
