How to Use CRLite for Certificate Revocation Checking in Firefox
Why Certificate Revocation Matters More Than You Think
Every time your browser connects to a website over HTTPS, it receives a TLS certificate from the server. That certificate contains a digital signature from a trusted Certificate Authority (CA), essentially vouching that the site is who it claims to be. But what happens when a certificate gets compromised, mis-issued, or associated with a domain that has changed hands? That's where certificate revocation comes in — and historically, it's been one of the messiest, most performance-impacting parts of the entire TLS ecosystem.
Firefox's new CRLite implementation represents a genuine technical leap forward. It's the first browser to deploy comprehensive, fast, and genuinely private certificate revocation checking at scale. For developers and security engineers, understanding how it works — and what it means for your infrastructure — is worth your time.
The Problem with Traditional Certificate Revocation
Before diving into CRLite, it helps to understand why revocation checking has been so problematic for so long.
OCSP: The Old Guard
The Online Certificate Status Protocol (OCSP) was the dominant approach for years. When a browser encounters a certificate, it sends a request to the CA's OCSP responder asking: "Is this certificate still valid?" The CA responds with "good," "revoked," or "unknown."
This approach has several well-documented problems:
Privacy leakage: Every OCSP request tells the CA exactly which website you're visiting, at what time, from which IP address. This is a significant privacy concern — you're essentially broadcasting your browsing activity to certificate authorities every time you visit an HTTPS site.
Performance overhead: OCSP checks add latency to every new TLS connection. Even with caching, this adds meaningful overhead, especially on mobile networks or when CAs have slow responders.
Soft-fail behavior: Because OCSP responders can be slow or unavailable, browsers historically implemented "soft-fail" — if the check times out, just proceed anyway. This means an attacker who can block OCSP traffic can effectively neutralize revocation checking entirely.
Incomplete coverage: OCSP stapling (where the server includes a pre-fetched OCSP response in the TLS handshake) helps with performance and privacy, but adoption has been inconsistent.
CRL: Comprehensive but Impractical
Certificate Revocation Lists (CRLs) are exactly what they sound like — lists of revoked certificate serial numbers published by CAs. They're comprehensive, but traditionally impractical for browsers because these lists can be enormous. Downloading a full CRL for a major CA could mean fetching megabytes of data for every browsing session.
How CRLite Actually Works
CRLite takes the comprehensiveness of CRLs and makes them practical through clever use of data structures and differential updates.
Bloom Filters and Cascading Filters
At its core, CRLite uses a cascading Bloom filter — a probabilistic data structure that can answer "is this item in this set?" with no false negatives and a controlled false positive rate.
Here's the clever part of the CRLite construction:
- Mozilla aggregates revocation data from CRLs published by all trusted CAs
- This data is compressed into a cascading Bloom filter structure
- The filter encodes all known revoked certificates across the entire web PKI
- This structure is small enough to download and store locally in Firefox
The cascading filter works by building multiple layers:
Layer 0: Contains all revoked certificates (some false positives)
Layer 1: Contains false positives from Layer 0 that are actually valid
Layer 2: Contains false positives from Layer 1 that are actually revoked
... and so on until the false positive rate is negligible
This structure achieves near-perfect accuracy with a fraction of the storage cost of raw CRL data.
Differential Updates
Rather than downloading the entire filter every time it's updated, Firefox receives small delta updates that patch the existing filter. This keeps bandwidth usage minimal while ensuring the revocation data stays current. Updates are pushed regularly, meaning Firefox has fresh revocation information without any per-connection network requests.
The Privacy Advantage
This is the critical distinction: because all revocation checking happens locally against a downloaded filter, no information about which certificates you're checking ever leaves your browser. Not to Mozilla, not to any CA, not to anyone. Compare this to OCSP, where every check is a network request that reveals your browsing activity.
What This Means for Your Web Infrastructure
If you're running web services, CRLite's deployment in Firefox has concrete implications for how you should think about your certificate hygiene.
Certificate Revocation Is Now Actually Enforced
Under the soft-fail OCSP model, a revoked certificate might still work in practice because browsers would fail open when checks timed out. With CRLite, Firefox checks revocation status locally against a comprehensive dataset. If your certificate appears in the revocation data, users will see an error — full stop.
This makes it more important than ever to:
- Rotate certificates promptly when private keys are compromised
- Monitor your certificate status proactively
- Ensure your CA is publishing CRL data that Mozilla can aggregate
Certificate Transparency Logs Matter
CRLite's comprehensiveness depends on Mozilla being able to aggregate revocation data from Certificate Transparency (CT) logs and CA-published CRLs. This means your certificates should be logged in CT logs (which is already required by most major CAs and browsers), and your CA should maintain up-to-date CRL endpoints.
You can verify your certificate's CT log status and overall validity using the SSL Certificate Checker — it gives you a clear view of certificate chain validity, expiration dates, and issuer information that can help you catch problems before your users do.
OCSP Stapling Still Matters (For Now)
Even with CRLite, OCSP stapling remains a best practice. Not all browsers have CRLite, and OCSP stapling provides a server-side mechanism to include fresh revocation status in the TLS handshake without requiring client-side checks. For nginx:
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
For Apache:
SSLUseStapling On
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
Auditing Your Certificate and DNS Configuration
Certificate validity doesn't exist in isolation — it intersects deeply with your DNS configuration. A certificate issued for the wrong domain, or DNS records pointing to the wrong server, can create security gaps that revocation checking alone won't catch.
Checking Your SSL Certificate Status
The first step in any certificate audit is verifying the basics: Is the certificate valid? Is it issued by a trusted CA? Is it within its validity period? Does the Subject Alternative Name (SAN) match your domain?
You can run a quick check with OpenSSL from the command line:
# Check certificate details for a domain
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -text
# Check expiration date specifically
echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates
# Verify the certificate chain
openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null
For a more comprehensive view without the command-line complexity, the SSL Certificate Checker provides a clear breakdown of certificate chain validity, SANs, expiration dates, and issuer details in a single interface.
DNS Configuration and Certificate Validity
Here's something developers often overlook: certificate revocation and DNS problems can produce similar symptoms from a user's perspective (connection errors, security warnings), but require completely different fixes.
Common DNS issues that interact with certificate validity:
CAA Records: Certification Authority Authorization (CAA) DNS records specify which CAs are allowed to issue certificates for your domain. If these are misconfigured, legitimate certificate renewals may fail:
# Check CAA records
dig CAA yourdomain.com
# Example correct CAA record format
yourdomain.com. 300 IN CAA 0 issue "letsencrypt.org"
yourdomain.com. 300 IN CAA 0 issuewild "letsencrypt.org"
yourdomain.com. 300 IN CAA 0 iodef "mailto:[email protected]"
TLSA Records (DANE): DNS-Based Authentication of Named Entities allows you to pin your TLS certificate information in DNS, providing an additional layer of verification:
# Check TLSA records
dig TLSA _443._tcp.yourdomain.com
Checking DNS propagation: When you renew or replace a certificate, DNS changes sometimes need to propagate before the new certificate is properly recognized. Use the DNS Lookup tool to verify your DNS records are resolving correctly across different nameservers and that your domain is pointing where you expect.
Monitoring Certificate Expiration
With certificate lifetimes being reduced over time (the CA/Browser Forum has been pushing toward shorter validity periods), automated monitoring is essential. Here's a simple bash script to check certificate expiration:
#!/bin/bash
DOMAIN="yourdomain.com"
EXPIRY=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null \
| openssl x509 -noout -enddate \
| cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_REMAINING=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))
echo "Certificate for $DOMAIN expires in $DAYS_REMAINING days"
if [ $DAYS_REMAINING -lt 30 ]; then
echo "WARNING: Certificate expires soon!"
# Add alerting logic here (email, Slack webhook, PagerDuty, etc.)
fi
You can run this as a cron job or integrate it into your monitoring pipeline.
The Broader Security Picture: Beyond Certificate Checking
CRLite is one piece of a larger web security puzzle. Certificate validity tells you that a connection is encrypted and the server's identity has been verified by a CA — but it doesn't tell you everything about your site's security posture.
Security Headers and HTTPS Enforcement
Even with a valid certificate, your site can be vulnerable if you're not enforcing HTTPS correctly. Key headers to implement:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
The Strict-Transport-Security (HSTS) header is particularly important — it tells browsers to always use HTTPS for your domain, even if a user types http:// in the address bar. The preload directive gets your domain added to browser preload lists, providing HSTS protection even on first visit.
Certificate Transparency Monitoring
Since CRLite depends on CT log data, you should be monitoring CT logs for unauthorized certificate issuances for your domain. Services like crt.sh allow you to search for all certificates ever issued for a domain:
# Using curl to query crt.sh API
curl -s "https://crt.sh/?q=yourdomain.com&output=json" | \
jq '.[].name_value' | sort -u
This can reveal if someone has obtained a certificate for your domain without your knowledge — a potential indicator of a domain hijacking attempt or CA mis-issuance.
API Endpoint Security
If your application exposes APIs over HTTPS, certificate validity applies to those endpoints too. Certificate errors on API endpoints can cause silent failures in integrations and third-party services that may not surface the same way browser errors do. The API Response Time Tester can help you verify that your API endpoints are responding correctly and that TLS handshakes are completing successfully, giving you both performance and connectivity data in one pass.
Practical Certificate Rotation Procedures
When you do need to revoke and replace a certificate — whether due to key compromise, mis-issuance, or CA issues — having a documented procedure matters.
Step-by-Step Certificate Rotation
1. Generate a new private key and CSR
# Generate new 4096-bit RSA key
openssl genrsa -out new-private.key 4096
# Or use ECDSA (recommended for performance)
openssl ecparam -name prime256v1 -genkey -noout -out new-private.key
# Generate CSR
openssl req -new -key new-private.key -out new-cert.csr \
-subj "/CN=yourdomain.com/O=Your Org/C=US"
2. Request the new certificate from your CA
Use the CSR to request a new certificate. For Let's Encrypt with Certbot:
certbot certonly --csr new-cert.csr --preferred-challenges dns-01
3. Deploy the new certificate
Update your web server configuration to point to the new certificate files, then test before reloading:
# Test nginx configuration
nginx -t
# Reload without dropping connections
nginx -s reload
4. Revoke the old certificate
With Let's Encrypt:
certbot revoke --cert-path /path/to/old-cert.pem --reason keyCompromise
5. Verify revocation propagation
After revocation, it takes some time for CRL data to propagate to Mozilla's CRLite aggregation pipeline. Monitor your certificate status and verify that the new certificate is serving correctly.
Staying Ahead of Certificate Issues
The shift toward more comprehensive revocation checking — exemplified by Firefox's CRLite deployment — means the consequences of certificate problems are becoming more immediate and harder to work around. The days of soft-fail OCSP giving you a grace period are fading.
The practical takeaway for developers and infrastructure engineers:
- Automate certificate renewal — manual renewal processes lead to expired certificates
- Monitor CT logs for your domains to catch unauthorized issuances early
- Configure CAA records to restrict which CAs can issue for your domain
- Implement OCSP stapling even as CRLite becomes more prevalent
- Test your full certificate chain regularly, not just the leaf certificate
- Document your rotation procedures before you need them in an emergency
Certificate infrastructure is one of those areas where problems tend to surface at the worst possible time — during high-traffic events, outside business hours, or when key personnel are unavailable. Proactive monitoring and tested procedures are the difference between a five-minute fix and a multi-hour outage.
Conclusion
Firefox's CRLite implementation is a significant technical achievement that makes certificate revocation checking both more reliable and more privacy-respecting than anything that came before. For web developers and security engineers, it's a signal that certificate hygiene is becoming a harder requirement — not a soft suggestion that browsers will quietly work around.
The good news is that the tools and practices to stay ahead of this are well-established. Automated renewal, CT log monitoring, proper DNS configuration, and regular certificate audits will keep you in good shape regardless of how browser revocation checking evolves.
Ready to audit your own certificate and DNS configuration? OpDeck provides a suite of free tools to help you check your SSL certificate status, verify DNS records, and test API endpoint availability — no sign-up required. Start with a quick SSL check on your primary domain and work from there.