OCSP privacy: the responder sees a certificate, not your URL

A status check asks one question about one certificate, and the answer travels on its own connection. It does not contain the page path that led to the check. Privacy discussions often treat the exchange as a browsing-history feed, which overstates what the request carries and understates what the responder can observe. Read the request before deciding what it reveals.

The request identifies one certificate

The OCSP certificate identifier is built from a hash function, two issuer hashes and the serial number of the target certificate, as specified in RFC 6960. Each field points at one certificate, not at a URL or an HTTP request.

The page path, the query string and any form contents are absent from the standard identifier. A claim that the responder receives the exact URL needs evidence from somewhere other than the certificate check. The request still names a certificate and a moment, and the responder may know which service presents it.

What is missing is the page, not the entire context. A certificate check plus a known service plus a repeated source can be more informative than any one of those alone.

What the responder can actually observe

The responder sees the connection that reaches it: source address, timing and whatever transport metadata its deployment records. If the status request follows the VPN, that source may be the VPN exit rather than the user's access network. Do not assume the status request takes the same path as the page request just because both belong to one browser session.

Check the client's supported routing and verification behavior instead of inferring it from a single trace. A split tunnel can send the two requests in different directions.

A stapled response is the other common pattern. The TLS status_request extension from RFC 6066 lets a server attach an OCSP response to its own handshake, so the client validates what it was given instead of fetching status itself for that connection. That shift changes the observer. The server side does the fetching, and the client's own address never reaches the responder for that connection.

Status can arrive stapled in the handshake

None of this guarantees that a client never makes another validation request. Chain building, status policy and supported mechanisms vary by implementation.

A certificate viewer in one browser is not a description of every operating system and VPN client. The same network capture can mean different things under different validation settings.

Caching breaks the one-page-one-lookup assumption

Caching decouples page loads from lookups. The browser may reuse a response for a period, so one page view does not imply one network request.

The opposite mistake is just as common. A cached response says nothing about when the next refresh happens, and the refresh schedule may be unrelated to the page being opened. Use the client's current documentation and the verification policy in force before attributing a capture to OCSP.

A valid status response has to meet the verifier's authenticity and freshness rules, and an HTTP 200 is not the same as a good status. A timeout is not a revocation. Those outcomes lead to different client behavior and should not be collapsed into one error.

Privacy choices that keep validation intact

Where the lookup itself is sensitive, discuss supported delivery and caching options with the system owner. Do not solve it by switching off revocation checking or chain validation.

A quieter trace is not a safer connection. Keep peer identity, chain validation and the intended revocation policy intact, and change the delivery path only through an option the deployment supports. Record which option was chosen and who owns it.

When a lookup appears unexpectedly, name the receiver, the route and the certificate operation separately. An issuer download, a status query and the page request are three events. Treating them as one makes the privacy review inaccurate and hides which party actually learned something. Start from the protocol fields and work outward to the network path.