OCSP and the Web PKI: What’s changing? | Ascertia Blog

Public key infrastructure (PKI) underpins trust for the web, email, code, devices and more. Recently, browsers and some public CAs have changed how they handle revocation for public TLS certificates. That raises a common question: is OCSP finished?

The short answer: for mainstream browsers, yes – live checks are being de-emphasised. But for everything else, absolutely not. OCSP remains the most efficient and essential way to check certificate revocation across enterprise, regulated and device PKIs.

Goodbye OCSP (for browsers). Long live OCSP (for everything else).

What’s changing in public TLS?

Browsers have long struggled with live, per-connection OCSP checks due to latency, privacy, and reliability trade-offs. To solve this, the industry is shifting towards browser-managed revocation feeds and short-lived certificates, instead of relying on live OCSP lookups during every TLS handshake.

• Chrome/Chromium: Uses CRLSets shipped by Google; online OCSP/CRL checks are not used by default.
• Microsoft Edge (Chromium): Online revocation checks are disabled by default; admins can enable soft-fail checks via policy.
• Firefox: Advancing CRLite, which compresses revocation data and enforces it locally, reducing need for live OCSP. Firefox’s CRLite work began in 2020 and has continued through 2025 alongside Root Store Policy updates.
• Let’s Encrypt: Ending OCSP for publicly-trusted TLS in 2025, relying on CRLs instead.

Takeaway for public websites: Expect less reliance on live OCSP and more on short lifetimes, stapling where appropriate, Certificate Transparency (CT) monitoring, and browser-distribution mechanisms like CRLite and CRLSets.

Where OCSP remains essential (non-Web PKI use cases)

Outside the consumer browser, revocation is often mission-critical. Many environments require hard-fail decisions if a certificate is revoked, and auditors demand provable evidence of status at the time of validation. OCSP is what enables this.

• Qualified e-signatures & seals (eIDAS/ETSI) – LTV (long-term validation) requires embedding revocation evidence (OCSP/CRLs), so signatures remain valid long after certificate expiry.
• Enterprise mTLS, VPN, and Zero Trust – Security gateways and firewalls frequently enforce live revocation, often preferring OCSP.
• Network and messaging infrastructure – Proxies, brokers, and middleware (e.g., IBM MQ, Symantec/Broadcom, Solace) rely on OCSP to secure communications.
• Code and platform trust – Operating systems and platforms still integrate OCSP/CRL checks into trust decisions and hardening.
• IoT and device identity – Device ecosystems use OCSP for runtime status enforcement, sometimes exposing dedicated OCSP endpoints.

What about stapling and must-staple?

OCSP stapling remains a best-practice optimisation whenever clients support it. The TLS Feature (RFC 7633), often called “Must-Staple”, lets you enforce stapled responses (fail if missing). This is especially valuable in controlled environments such as enterprise browsers and internal services, though it’s not universally enforced by public browsers.

Practical steps for PKI owners

Separate your policies

• Public websites: Prioritise short-lived certs, enable stapling where possible, and continuously monitor. Assume browsers won’t perform live OCSP.
• Enterprise and regulated environments: Keep OCSP in your workflows to enable runtime checks and audit trails.

Engineer OCSP for reliability

• Deploy highly available responders.
• Use short validity windows.
• Leverage delegated OCSP signers, HSMs, caching, and detailed health checks for forensic proof.

Use policy to enforce hard-fail where it counts

• Managed browsers (e.g., Edge) allow revocation policy control.
• Security infrastructure can be set to prefer OCSP and fail closed.
• For signatures and seals embed revocation evidence for long-term validation (LTV) compliance.
• Ensure signing and augmentation workflows collect and embed OCSP/CRL material to meet ETSI validation requirements.

Common pitfalls to avoid

• Assuming browser behaviour applies everywhere: It doesn’t. Many enterprise systems likely expect live revocation.
• Relying on CRLs only in high-change environments: OCSP delivers fresher answers, per certificate, with less lag.
• Skipping evidence capture: Without stored OCSP responses (or embedding in LTV), audits and disputes are harder to resolve.

Seamless revocation with Ascertia

Ascertia’s ADSS OCSP Server (Validation Authority) provides high-performance, RFC 6960/RFC 5019-compliant OCSP with flexible deployment options, from high availablilty and delegated signers to fine-grained policy control. It’s built for enterprise TLS, VPN, S/MIME, code signing and IoT ecosystems.

For organisations modernising validation across complex environments, the ADSS OCSP Server integrates seamlessly with Ascertia’s ADSS Server services (SCVP, CRL monitoring, timestamping) to create complete, audit-ready validation workflows.

Building the future of trust with Ascertia

Revocation checking is evolving, but it’s far from disappearing. While browsers are reducing their reliance on live OCSP, regulated industries, enterprises, and connected devices depend on it more than ever.

Ascertia helps organisations strike the right balance: combining OCSP with stapling, policy enforcement, and futureproof validation services.

Is your organisation planning its next phase of PKI? Let’s explore how Ascertia’s trusted solutions can help you build resilient, compliant, and forward-looking validation strategies.