CA root rollover with two-root overlap and safe retirement (#285 T7) #297

New issue

Open

opened 2026-11-01 17:28:21 +00:00 by kayg · 0 comments

kayg commented

2026-11-01 17:28:21 +00:00

Owner

Follow-up from #285 T7. This issue owns the actual certificate-authority root switch. #285 Part A prepares public status and two-root trust parsing only; it does not generate or activate a new root.

Scope

Design and implement the root rollover protocol after an owner grill. The rollout must publish and validate both the current and next public roots before any issuer switch. Keep the old root trusted until every certificate issued by it has expired or been replaced. Preserve issuer generation on certificate records, and make metadata changes atomic across restart and recovery.

Owner grill before implementation

Confirm the switch trigger and approval, how compatible clients prove they understand the overlap bundle, the behavior when a required host stays offline, and how an interrupted switch is resumed or rolled back. Do not weaken existing client-certificate verification or create a new root implicitly.

Acceptance criteria

Mixed-version clients keep existing trust and cannot cause a premature switch.
The new issuer and its generation are durable before certificates are issued under it.
Existing and newly issued leaves validate throughout the overlap.
The old root is removed only after no unexpired leaf depends on it.
Crash, cold restart, locked CA, offline hosts and lost acknowledgements have tested outcomes.
Public status and audit output contain no private CA material.

Follow-up from #285 T7. This issue owns the actual certificate-authority root switch. #285 Part A prepares public status and two-root trust parsing only; it does not generate or activate a new root. ## Scope Design and implement the root rollover protocol after an owner grill. The rollout must publish and validate both the current and next public roots before any issuer switch. Keep the old root trusted until every certificate issued by it has expired or been replaced. Preserve issuer generation on certificate records, and make metadata changes atomic across restart and recovery. ## Owner grill before implementation Confirm the switch trigger and approval, how compatible clients prove they understand the overlap bundle, the behavior when a required host stays offline, and how an interrupted switch is resumed or rolled back. Do not weaken existing client-certificate verification or create a new root implicitly. ## Acceptance criteria - Mixed-version clients keep existing trust and cannot cause a premature switch. - The new issuer and its generation are durable before certificates are issued under it. - Existing and newly issued leaves validate throughout the overlap. - The old root is removed only after no unexpired leaf depends on it. - Crash, cold restart, locked CA, offline hosts and lost acknowledgements have tested outcomes. - Public status and audit output contain no private CA material.

kayg referenced this issue

2026-11-01 17:32:08 +00:00

Machine trust: self-renewal and 7-day key rotation #285

kayg referenced this issue

2026-11-01 18:26:23 +00:00

Machine trust: self-renewal and 7-day key rotation #285

kayg referenced this issue

2026-11-01 18:51:50 +00:00

Machine trust: self-renewal and 7-day key rotation #285

kayg referenced this issue

2026-11-01 19:00:14 +00:00

Machine trust: self-renewal and 7-day key rotation #285