How do you migrate from one Certificate Authority to another without an outage?
Switching CAs touches chain construction, any pinning you deployed, and client trust stores. The danger is a mismatch between the leaf, the intermediates you serve, and what clients expect. Migration sequence.
— Map the new chain fully: the new leaf plus every intermediate up to a root already in the major trust stores. Serve the intermediates; do not assume clients fetch them via AIA.
— If you ever deployed HPKP-style pinning or app-level pins, that is your blocker. Stage new pins for the incoming CA's keys alongside the old ones with a backup pin, well before cutover.
— Test the assembled chain with openssl verify -untrusted chain.pem leaf.pem and with SSL Labs to catch incomplete-chain errors that only some clients hit.
— Cut over by swapping the cert and chain atomically, then reload; keep the old cert deployable for instant rollback.
— Watch CT logs and your own error rates for chain-validation failures from older Android and embedded clients with stale roots.
Evidence vs. speculation: 'works in my browser' hides incomplete-chain failures that only affect clients lacking the intermediate cached.
Further reading: RFC 5280 section 6 (path validation); CA/Browser Forum Baseline Requirements.
Bottom line: chain completeness and any pre-existing pins, not the leaf itself, are what break migrations.
Handshake Papers
@HandshakePapers
How do you migrate from one Certificate Authority to another without an outage?
Этот пост опубликован в Telegram-канале Handshake Papers. Подписаться можно по ссылке: @HandshakePapers.