Use S3 object expiry for OCSP snapshots

This commit is contained in:
2026-10-28 19:39:51 +00:00
parent 9da68a9625
commit a7cfda4167
17 changed files with 321 additions and 238 deletions
+9 -6
View File
@@ -203,12 +203,15 @@ bucket and ships a standalone Rust/Axum responder on port `2560`.
configured S3 prefix and uses a delegated OCSP signing certificate/key per
CA.
- Each CA snapshot is cached for one second with a single-flight refresh, so
concurrent requests cause at most one S3 `GetObject` per CA per second.
- The publisher refreshes unchanged snapshots every 30 seconds by default. The
responder rejects snapshots older than its configured grace period even when
S3 is readable, and returns `tryLater` when no fresh snapshot is available.
- OCSP `thisUpdate` reflects the snapshot generation time and `nextUpdate` never
extends beyond the snapshot's hard expiry.
concurrent requests cause at most one S3 `HeadObject` plus conditional
`GetObject` sequence per CA per second. The ETag condition keeps the body and
expiry metadata from different object versions from being combined.
- The publisher refreshes unchanged snapshots every 30 seconds by default and
sets each object's `Expires` header 60 seconds in the future. The responder
rejects expired objects even when S3 is readable and returns `tryLater` when
no unexpired snapshot is available. S3 does not delete objects at `Expires`.
- OCSP `thisUpdate` is the response time and `nextUpdate` never extends beyond
the snapshot's hard expiry.
- Gitea Actions publishes `gitea.woggioni.net/woggioni/kca-ocsp` on the same
`release/*` tags as the server image. The responder image is a statically
linked musl executable running `FROM scratch` with only the CA bundle.