The question that stalls most rollover plans — "which procedure applies to this CA?" — is one goca answers for you. POST /v1/cas/{ca}/rollover (console: the CA card's Rollover action) resolves the mode itself — you are told, not asked:
- Self-signed root → the new generation self-signs, active immediately.
- Parent hosted here and signable → signed in the same call.
- Parent external or offline → CSR mode: the new key is generated, the generation parks in
pending-cert, and you get a CSR. Issuance continues on the current generation while the signature is pending — a rollover never disrupts service.
After cutover, the previous generation moves to rollover state: it stops issuing but keeps signing its own CRLs until its issued population expires.
Two more fields ride the same call. An algorithm in the body switches algorithms at rollover — this is precisely the mechanism a classical→PQC migration rides. And custody moves a key between software, strict provider and wrapped custody — because custody, like the algorithm, is decided when the generation's key is minted and at no other time.
Now I can roll a CA generation — including to a new algorithm — without stopping service.