Revoking a certificate is only half the job — the other half is telling every client that reads it that it has been revoked. TigerTrust handles both mechanisms defined by RFC 5280 and RFC 6960: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). Both are backed by the same revocation store, so they always agree.

​
What it is

Every internal CA you create automatically publishes CRLs and answers OCSP queries. Every certificate issued by an internal CA embeds the CRL distribution point and OCSP responder URLs in the certificate itself, so relying parties know where to check.

​
When to use it

  • Enable OCSP stapling on your TLS servers so clients don’t need to phone home during handshakes.
  • Tune the CRL refresh interval for a high-value CA to minimize the window between a revocation and client awareness.
  • Generate a CRL on demand immediately after a key compromise incident.
  • Add OCSP Must-Staple to certificates issued to services you can guarantee will always staple.

CRL

Batch, signed list downloaded periodically. Cacheable, works offline. Latency = nextUpdate interval (default 7 days).

OCSP

Real-time per-serial lookup. Low staleness, requires a reachable responder. Ideal for high-value certificates.
Best practice: publish both, and enable OCSP stapling so servers hand the response to clients inline in the TLS handshake.

​
Set it up

1

Generate a CRL on demand

Go to PKI Management, open a CA, and click Generate CRL. The CRL is immediately available at the distribution point URL embedded in your certificates.
2

Configure CRL refresh interval

Open the CA settings and set the CRL refresh interval (default 7 days). For high-value CAs, set this to 1–24 hours. TigerTrust regenerates the CRL automatically on this schedule.
3

Enable OCSP stapling on your servers

Point your web server’s OCSP responder configuration at the URL shown in PKI Management > CA > OCSP endpoint. Example configurations for common servers are shown below.
4

Enable OCSP Must-Staple (optional)

In a certificate template, enable OCSP Must-Staple to add the TLS Feature: status_request extension. Browsers then reject the certificate if no stapled OCSP response is present in the TLS handshake.

​
CRL distribution points

Every certificate issued by an internal CA embeds a crlDistributionPoints extension. The default URL pattern is: 
https://crl.tigertrust.io/pki/<ca-id>.crl
You can override this per CA — useful for serving CRLs from a CDN or S3 bucket. The CRL URL is unauthenticated and publicly reachable by design; the CA’s signature on the CRL is the trust anchor, not the endpoint’s access control.

​
OCSP stapling configuration

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
TigerTrust’s field agent can automate stapling refresh — it queries the OCSP responder on a schedule and pushes the response to the servers it manages.

​
Performance

CRL fetches

Serve CRLs behind a CDN — they are immutable within their nextUpdate window. Set Cache-Control: public, max-age=<seconds-until-next-update>.

OCSP responses

Typical response time is under 10 ms. Deploy the responder close to your servers if stapling is not feasible.

Certificate revocation

How certificates enter the revocation store that CRL/OCSP publish from.

PKI Core

The service that signs CRLs and answers OCSP queries.

Certificate authorities

Per-CA distribution point and OCSP endpoint configuration.