How Safari Handles OCSP Stapling and Revocation Checks

This article provides a quick overview of how Apple's Safari web browser manages SSL/TLS certificate revocation to keep users secure without sacrificing privacy or browsing speed. It explains how Safari relies on underlying operating system frameworks to process Online Certificate Status Protocol (OCSP) stapling, how Apple implements its own centralized, CRLite-style revocation checking system to verify certificates locally, and what happens when the browser must fall back to traditional network checks.

Operating System Integration

Unlike browsers that maintain their own independent certificate stores and verification engines, Safari delegates certificate verification to the underlying operating system (macOS, iOS, or iPadOS). A background system daemon known as trustd handles all TLS trust evaluations. Consequently, Safari's approach to OCSP stapling and CRLite-style checks is actually an OS-level process that benefits both Safari and any third-party applications using Apple’s native networking APIs.

How Safari Handles OCSP Stapling

OCSP stapling is a standard that allows a web server to proactively fetch a signed, timestamped OCSP status response from a Certificate Authority (CA) and attach—or "staple"—it directly to the TLS handshake when a user connects.

Safari fully supports OCSP stapling. When you visit a website, the process works as follows:

  1. Handshake Inspection: During the TLS handshake, Safari (via trustd) checks if the web server has included a stapled OCSP response.
  2. Local Validation: If a staple is present, the system verifies the cryptographic signature of the response and checks the timestamp to ensure it has not expired.
  3. Connection Approval: If the stapled response confirms the certificate is valid, Safari immediately completes the connection.

By using OCSP stapling, Safari avoids making a separate, real-time network request to the CA. This speeds up the connection and protects user privacy, as the CA is not informed of which websites the user is actively visiting.

Apple’s CRLite-Style Revocation System

When a website does not use OCSP stapling, browsers need another way to check if a certificate has been revoked. Historically, browsers downloaded massive Certificate Revocation Lists (CRLs) or queried the CA directly. To solve the performance and privacy issues of these older methods, Mozilla pioneered "CRLite," a system that compresses all known revoked certificates into tiny, efficient data structures (cascading Bloom filters) and pushes them to the browser for local checking.

Apple uses a nearly identical, CRLite-style architecture for Safari, managed through a service connected to valid.apple.com. Here is how Apple’s implementation works:

  1. Aggregation: Apple’s servers continuously fetch revocation data (CRLs and OCSP data) from all publicly trusted Certificate Authorities included in the Apple Root Program.
  2. Compression: Apple compiles this massive amount of revocation data into a highly compressed, space-efficient format.
  3. Distribution: This bundled revocation data is periodically pushed to macOS and iOS devices in the background.
  4. Local Evaluation: When Safari encounters a certificate without an OCSP staple, trustd checks the certificate against this local, on-device database.

Because the check happens entirely on the user's device, it is instantaneous and completely private. If the certificate is flagged as revoked in Apple's local database, Safari blocks the connection and displays a security warning.

The Fallback Mechanism: Live OCSP Checks

In scenarios where a web server does not provide an OCSP staple, and the local CRLite-style database cannot definitively verify the status of a specific certificate (for example, if the local database is outdated or the certificate requires additional constraints), Safari falls back to a live OCSP check.

During a live check, the operating system sends a request directly to the issuing CA's OCSP responder over the network. To prevent slow or unreachable CA servers from breaking the user's browsing experience, Safari utilizes a "soft-fail" policy. If the CA's OCSP server is down or fails to respond within a strict time limit, Safari assumes the certificate is still valid and allows the connection to proceed. A connection is only blocked during a live check if the OCSP responder explicitly replies that the certificate has been revoked.