Doctor plugin checks: implement health check classes and documentation
Implement remediation-aware health checks across all Doctor plugin modules (Agent, Attestor, Auth, BinaryAnalysis, Compliance, Crypto, Environment, EvidenceLocker, Notify, Observability, Operations, Policy, Postgres, Release, Scanner, Storage, Vex) and their backing library counterparts (AI, Attestation, Authority, Core, Cryptography, Database, Docker, Integration, Notify, Observability, Security, ServiceGraph, Sources, Verification). Each check now emits structured remediation metadata (severity, category, runbook links, and fix suggestions) consumed by the Doctor dashboard remediation panel. Also adds: - docs/doctor/articles/ knowledge base for check explanations - Advisory AI search seed and allowlist updates for doctor content - Sprint plan for doctor checks documentation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
57
docs/doctor/articles/timestamping/revocation-cache-fresh.md
Normal file
57
docs/doctor/articles/timestamping/revocation-cache-fresh.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
checkId: check.timestamp.revocation.cache-fresh
|
||||
plugin: stellaops.doctor.timestamping
|
||||
severity: warn
|
||||
tags: [timestamping, revocation, cache, ocsp, crl]
|
||||
---
|
||||
# Revocation Cache Freshness
|
||||
|
||||
## What It Checks
|
||||
Checks that cached OCSP responses and CRLs are not stale. The check:
|
||||
|
||||
- Queries the revocation cache for OCSP response and CRL snapshot timestamps.
|
||||
- Compares each cached item's age against thresholds: OCSP max age (default 12 hours), CRL max age (default 7 days).
|
||||
- Fails if all cached items are stale. Warns if some are stale.
|
||||
- Passes if no cached data exists (optional) or all items are fresh.
|
||||
|
||||
## Why It Matters
|
||||
Stale revocation data means the system may accept certificates that have been revoked since the cache was last updated. For air-gapped environments that cannot perform live lookups, a fresh cache is the only source of revocation information.
|
||||
|
||||
## Common Causes
|
||||
- Revocation cache refresh job not running
|
||||
- Network issues preventing OCSP/CRL fetches
|
||||
- Cache storage issues
|
||||
|
||||
## How to Fix
|
||||
|
||||
### Docker Compose
|
||||
```bash
|
||||
# Refresh revocation cache
|
||||
docker exec <platform-container> stella revocation cache refresh
|
||||
```
|
||||
|
||||
### Bare Metal / systemd
|
||||
```bash
|
||||
stella revocation cache refresh
|
||||
|
||||
# Schedule automatic refresh
|
||||
stella revocation cache schedule --ocsp-interval 6h --crl-interval 24h
|
||||
```
|
||||
|
||||
### Kubernetes / Helm
|
||||
```yaml
|
||||
timestamping:
|
||||
revocationCache:
|
||||
ocspMaxAgeHours: 12
|
||||
crlMaxAgeDays: 7
|
||||
refreshSchedule: "0 */6 * * *"
|
||||
```
|
||||
|
||||
## Verification
|
||||
```
|
||||
stella doctor run --check check.timestamp.revocation.cache-fresh
|
||||
```
|
||||
|
||||
## Related Checks
|
||||
- `check.timestamp.ocsp.responder` — checks OCSP responder availability
|
||||
- `check.timestamp.crl.distribution` — checks CRL distribution point availability
|
||||
Reference in New Issue
Block a user