OCSP packets not seen in a Proxy Chain Deployment - Best Practice
search cancel

OCSP packets not seen in a Proxy Chain Deployment - Best Practice

book

Article ID: 411327

calendar_today

Updated On:

Products

ISG Proxy

Issue/Introduction

A customer has a Proxy Chain environment and is attempting to implement OCSP on a child Proxy, while disabling the same on the Parent Proxy, and they aren't seeing any OCSP packet.

Environment

Proxy Chain Deployment: ISG-Proxy

Cause

Proxy Chain Layout

  • Child Proxy → forwards all outbound requests to → Parent Proxy → Internet.

  • Customer has:

    • OCSP enabled on Child Proxy.

    • OCSP disabled on Parent Proxy.

Why They See No OCSP Packets

  1. Child Proxy never sees the real server certificate

    • In a chain, the parent proxy is the one that actually connects to the Internet web server and receives the original certificate.

    • The child proxy only sees the reissued/intercepted certificate from the parent proxy’s SSL interception (signed by the parent’s local CA).

  2. OCSP can’t validate a reissued local certificate

    • When OCSP runs on the child proxy, it tries to check the certificate it sees (signed by the parent’s CA).

    • The AIA field in that certificate points to the parent’s CA (not a public CA like DigiCert).

    • That CA does not have a public OCSP responder, so there’s nowhere to send a query.

    • Result: the child proxy doesn’t generate any OCSP traffic.

  3. Parent Proxy is the correct place

    • Since the parent proxy sees the real Internet certificates, it’s the only device that can query the correct OCSP responders (e.g., ocsp.xxxxxxxxxx.com)).

    • Disabling OCSP on the parent removes this validation entirely.

Resolution

Best Practice

  • Enable OCSP on the parent (Internet-facing) proxy, not the child.

  • If multiple child proxies exist, let them forward traffic to the parent without doing OCSP.

  • The parent proxy validates the true certificates against the CA’s OCSP responders.

So the reason the customer sees no OCSP packets is because they enabled it in the wrong place (child proxy). Implementing OCSP on a child proxy (downstream proxy that forwards to another proxy) is usually not useful and sometimes misleading.

It should be enabled on the parent proxy (egress) where the real certificates are visible.

 

Notes:

What is an OCSP Server?

  • An OCSP server (often called an OCSP responder) is a service run by a Certificate Authority (CA).

  • Its job: respond to queries about whether a certificate is valid, revoked, or unknown.

  • Example: if a server presents a certificate issued by DigiCert, the OCSP responder might be at ocsp.xxxxxxxxxx.com).

 

How OCSP Works (simplified flow)

  1. Client (or ProxySG) receives a server certificate during an SSL/TLS handshake.

  2. ProxySG looks inside the certificate - most certificates contain an AIA (Authority Information Access) field, which includes a URL for the OCSP responder.

    • Example: http://ocsp.xxxxxxxxxx.com)

  3. ProxySG makes an HTTP (or sometimes HTTPS) request to that OCSP server:

    • “Is this certificate with serial number XYZ still valid?”

  4. OCSP server responds with a signed message: Good / Revoked / Unknown.

 

Where the OCSP Server Fits in ProxySG deployment

Imagine traffic flow in explicit proxy mode with SSL interception:

Client → ProxySG → Origin Server (Internet)

  • ProxySG intercepts SSL and validates the certificate.

  • To check revocation:

    • ProxySG → (directly or via forwarding rules) → OCSP Server (CA infrastructure on the Internet).

So the OCSP server is external to ProxySG, operated by the CA that issued the site’s certificate. ProxySG is the client in this exchange.

 

Now, if OCSP is enabled on the parent (egress) ProxySG and disabled on the child, yet you still don’t see any OCSP traffic, it’s usually one (or a combo) of the reasons below. I’ll keep this practical and ordered from most-to-least common.

Why you may see no OCSP packets (even with “correct” parent setup)

  1. Valid OCSP stapling from the origin server

    Normal OCSP (without stapling)

    • When a client (or proxy) connects to a server, it receives the server’s certificate.

    • To check revocation, the client must contact the CA’s OCSP responder (e.g., http://ocsp.xxxxxxxxxx.com).

    • That’s an extra round trip over the Internet, adding latency

    What is OCSP Stapling?

    • OCSP Stapling is an optimization defined in RFC 6066 (TLS extension).

    • Instead of forcing every client to query the CA, the server itself periodically fetches an OCSP response from the CA.

    • During the TLS handshake, the server “staples” (attaches) this fresh OCSP response to its certificate.

    • The client (or proxy) can then validate the certificate immediately, without generating its own OCSP request.

      • Many sites staple an OCSP response inside the TLS handshake.

      • If the parent receives a valid stapled OCSP for the leaf cert, no outbound OCSP query is needed, so you won’t see any OCSP packets.

  2. OCSP response already cached on the parent

      • The parent caches OCSP responses (per the responder’s nextUpdate or your TTL override).

        • The parent proxy (Internet-facing ProxySG) is the one that:

          1. Receives the real server certificates during SSL interception.

          2. Performs the OCSP check (since OCSP is enabled there).

          3. Stores the OCSP responder’s reply in its local OCSP cache.

        • So “parent” = the upstream ProxySG in the chain, the one that connects to the Internet.

      • Subsequent connections during the cache lifetime produce no new OCSP lookups.

    • On ProxySG, OCSP caching is by design - to avoid flooding responders with repeat queries for every TLS handshake. If the parent proxy already has a valid OCSP response cached, you won’t see any outbound OCSP traffic until the cache entry expires.

      Here’s how you can verify and (if needed) deal with cached OCSP responses:

      How to Verify if the Response Is Cached

      1. Policy Trace (most direct)

        • Run a policy trace while accessing the affected HTTPS site:

        • Look for messages like:

          • Validating certificate for <hostname>

          • OCSP: using cached response (means it did not send a query)

          • OCSP: querying responder <URL> (means a fresh query was sent).

      2. Check the Certificate AIA URL

        • Get the certificate from the site (browser or ProxySG SSL tab).

        • In the details, look for Authority Information Access (AIA).

          Example:

          Authority Information Access:
             OCSP - URI:http://ocsp.xxxxxxxxxx.com)

        • This tells you which responder ProxySG would query when it needs to refresh See the snippet below, as reference.

      3. Packet Capture

        • If you capture on the parent proxy’s egress and you don’t see OCSP requests but the site validates, that’s evidence ProxySG used a cached response.

        • If you force expiry (see below), you should see fresh OCSP packets.

      How to Deal With Cached Responses

      1. Wait for Expiry

        • The cache lifetime is defined by the nextUpdate field inside the OCSP response (often 1-7 days).

        • ProxySG will not refresh until that time passes.

      2. TTL Override (for testing)

        • Go to Configuration > SSL > OCSP.

        • Set a low value for Response Cache TTL Override (e.g., 1 minute).

        • This forces ProxySG to query the OCSP responder more frequently.

        • Restore the default after testing to avoid unnecessary responder load.

      3. Policy Trace Confirmation

        • After lowering TTL, run a new trace.

        • You should see OCSP: querying responder http://… again, confirming that cache expiry triggered a fresh request.

 

ProxySG OCSP Implementation Details

  • When you enable OCSP on ProxySG, you configure:

    • Whether it uses HTTP or HTTPS for queries.

    • TTL/override (how long to cache the response).

    • Optionally, a forwarding host if you want OCSP queries to flow via another proxy.

  • ProxySG automatically reads the OCSP URL from the certificate and contacts that responder.

  • If the responder is unreachable, ProxySG can fall back to CRL (Certificate Revocation List) if configured.

 Ref.: Configure OCSP to perform real-time certificate revocation status checks

 

Summary

  • OCSP server = Certificate Authority’s responder service (public-facing, Internet-based).

  • ProxySG acts as an OCSP client.

  • The OCSP server is not inside ProxySG - it is part of the CA ecosystem (like DigiCert, GlobalSign, Entrust).

  • ProxySG just sends queries there whenever it needs to validate an intercepted certificate.

Additional Information

 

 

Here’s a clear flow diagram.

  • Child → Parent: Sends the client HTTP request. No OCSP, since the child never sees the real server certificate.

  • Parent → Origin Server: Establishes the TLS session and validates the real certificate.

  • Parent → OCSP Responder: Generates and sends the OCSP POST (routed according to forwarding rules if enabled).

This makes it explicit that only the parent generates OCSP packets, while forwarding simply controls how those packets reach the responder.

Powered by Wolken Software