Rethinking Certificate Revocation at Snowflake

At Snowflake, we are changing how our drivers handle TLS certificate revocation checking. We're moving away from online certificate status protocol (OCSP); adopting Certificate Revocation Lists (CRLs); and, after a thorough review of our threat models, shifting to a default stance of disabled revocation checking in Snowflake drivers. This change is accelerated by our broader migration to new Certificate Authorities: Let's Encrypt and Google Trust Services, which have either already discontinued OCSP support or have announced plans to do so.

This post walks through the problems with OCSP, why CRLs are a better fit, what the industry is doing and where we're headed. Our long-term goal is short-lived certificates for all Snowflake-owned endpoints, and we plan to take you through that journey over the next year.

What is certificate revocation?

Certificates used for HTTPS (TLS) are issued by a certificate authority (CA) and are valid for a fixed lifetime, currently capped at one year. If a certificate is compromised by an attacker, replaced by the owner or issued in error, clients need a way to detect that the certificate is no longer valid. There are two common mechanisms for this: OCSP and CRLs.

How quickly can a compromised certificate be detected?

Before any client can detect that a certificate has been revoked, several things must happen:

1. The certificate owner must detect the compromise. Realistically, this takes days, weeks or months.
2. The owner must contact the CA to request revocation. This step is sometimes missed or delayed during incident response.
3. The CA must update its OCSP responder and CRLs. Prior responses remain valid until their next scheduled update. That window can be up to 10 days, as set by CA/Browser Forum Baseline Requirements.
4. Clients must fetch a fresh OCSP response or updated CRL.

Even with real-time revocation checking, a client is likely to see a revocation weeks after a compromise, not hours. This is the fundamental reality of how global certificate infrastructure operates today, and it is essential context for evaluating any revocation mechanism.

OCSP in practice: Our experience

OCSP was designed to provide real-time certificate status directly from CAs. Snowflake deeply integrated it into our drivers, adding centralized caching and a fail-open mode to improve reliability. In practice, however, OCSP has introduced persistent operational challenges.

Reliance on external infrastructure: OCSP responders are servers run by CAs that handle status queries in real time. Their availability and latency directly affect every customer running a Snowflake driver. Downtime can cause connection failures at scale, since the responder is a single point of failure for all clients. To compensate, we built a centralized caching layer, which moves the complexity rather than eliminating it.

Bespoke, fragile implementations: Most TLS libraries and SDKs don't include revocation checking out of the box, so Snowflake built it independently across each driver. Bespoke implementations are difficult to get right and difficult to maintain. Any bug or fix requires customers to upgrade their driver, which is a frequently reported pain point, and failures manifest in the worst possible way: an inability to connect to Snowflake.

Fail-open is a security theater: Because OCSP responders are unreliable, most implementations fall back to fail-open mode: If the responder is unreachable, the connection proceeds under the assumption that the certificate is valid. This creates a trivially exploitable attack vector: An attacker only needs to prevent the client from reaching the OCSP responder, and the revocation check is silently bypassed. In practice, fail-open OCSP provides little meaningful security.

Privacy leakage: OCSP requests reveal which certificates are being checked. These requests travel over unencrypted channels, exposing connection metadata to the OCSP responder and any observer on the network path, including public Wi-Fi operators.

Why not OCSP stapling?

OCSP stapling is a variant where the server fetches and presents a CA-signed OCSP response alongside its certificate, removing the client's need to contact the OCSP responder directly. This addresses the availability concern (the server bears the burden) and the privacy concern (the client reveals nothing). On paper, it looks like a clean solution.

In practice, it has two problems. First, prior to TLS 1.3, stapling did not support multiple responses, making it impossible to validate both intermediate and end-entity certificates in the same handshake. Given the range of environments Snowflake clients run in, we need a solution that works broadly.

Second, and more decisively, several major CAs, including Let's Encrypt and Google Trust Services, have announced they will no longer support OCSP at all. Snowflake is migrating to these CAs for the efficiency and supportability benefits they offer — with OCSP discontinued by our new CAs, stapling is simply not a viable long-term path.

Moving to CRLs

Certificate Revocation Lists take a different approach. Rather than a live query per certificate, the CA periodically publishes a signed list of all revoked certificate serials. Clients download it once, cache it locally, and consult the cache for subsequent connections.

This design offers meaningful practical advantages:

• Better availability: CRLs are static, signed files that can be served via CDN and cached aggressively. If a CA's distribution point is temporarily unavailable, clients continue operating with a cached copy.
• Privacy preserved: There are no outbound requests per connection that expose which service a client is accessing.
• A well-defined standard: CRLs are a native CA mechanism supported by most TLS libraries, not a custom layer we built on top of a flawed protocol.

CRLs carry similar trade-offs to our existing OCSP response cache: They reflect the CA's state at the time of publication, not in real time. But they're a standard native to the CA ecosystem, comparable to our bespoke cache in what they provide, without the operational and maintenance burden.

What about CRLSets and CRLite?

The browser ecosystem is converging on CRL-based alternatives like CRLSets (used by Chrome) and CRLite (a compact probabilistic filter). These shift trust from the CA to the browser vendor and provide high availability with strong privacy properties. We consider them a possible future direction for optimization but not a target in the near term.

The industry is moving the same direction

Snowflake is not alone in this shift. The CA/Browser Forum, which governs public TLS certificate infrastructure, passed a ballot in 2023 allowing CAs to issue certificates without OCSP responders. Adoption has been rapid: Let's Encrypt stopped issuing certificates with OCSP responders in late 2024, and Google Trust Services is rolling out the same change. The industry has "decided to put an end to a long struggle with revocation checking," and Snowflake's direction is aligned with where it's going.

The bigger picture: Short-lived certificates

There is a more fundamental change underway that will eventually render revocation checking unnecessary altogether: The industry is shifting to short-lived certificates.

Today, certificates are valid for up to 12 months. A compromised certificate can be used by an attacker for that entire remaining duration, and as we've established, it may take weeks before revocation propagates to clients. That's an unacceptably large window.

The CA/Browser Forum has mandated progressively shorter certificate lifetimes, with a maximum of 47 days by 2029. The logic is direct: If revocation responses are treated as valid for up to 10 days, then a certificate with a shorter lifetime provides no meaningful additional window for an attacker. The certificate expires before a revocation check would be useful.

Snowflake plans to move ahead of this timeline. We are actively working to migrate our endpoints to certificates with lifetimes under seven days, which effectively eliminates the need for client-side revocation checking entirely.

What's changing in Snowflake drivers

The most visible near-term change: Snowflake drivers will disable TLS certificate revocation checking by default.

This is a deliberate decision grounded in the analysis above. Several factors converge on a clear conclusion: detection windows measured in weeks rather than hours, the operational fragility of OCSP, the deprecation of real-time revocation across the industry, and our roadmap to short-lived certificates. Together, they show that the reliability cost of mandatory revocation checking outweighs its security benefit given the infrastructure that exists today.

We are not reducing our security posture; we are refocusing it on controls that actually work. This reflects Snowflake's broader security philosophy: Instead of bolting on checks that depend on third-party infrastructure and degrade under attack, we engineer the underlying system so these risks are addressed at the source:

• Rigorous certificate lifecycle management: We maintain strict internal processes for issuance, renewal and proactive revocation. Client-side checks have never been the primary control here.
• Short-lived certificates: Eliminating long-lived certificates removes the attack window that revocation checking is designed to close, addressing it at the root rather than patching around it.
• Opt-in CRL checking: For customers with specific compliance requirements or who want additional defense in depth, CRL-based revocation checking will be available as an opt-in configuration.
• All client communication is end-to-end encrypted: The only unencrypted (HTTP) traffic from drivers is OCSP and CRL traffic, as these protocols need to precede TLS handshake completion with revocation enabled. With these eliminated, all driver traffic is now using TLS 1.2 or 1.3.

One practical action to take now: Do not hardcode CA roots for any Snowflake endpoint. As we migrate to Let's Encrypt and Google Trust Services, hardcoded roots will cause connection failures. We also recommend restricting outbound connections from your environment to Snowflake and CSP storage endpoints only, which provides network-layer control independent of certificate revocation.

References

• End of Life - OCSP Support