For a certificate nearing expiry, what distinguishes renewal from re-keying, and which does a suspected private-key compromise force?
answer
- both end in a new certificate
- the difference is upstream of issuance
- same public key, or a new one
- who benefits from a reissue over the old key
- SubjectPublicKeyInfo unchanged means renewal
basics
~20 sRenewal issues a new certificate over the same public key; re-keying generates a new key pair first, so the new certificate carries a different SubjectPublicKeyInfo. A suspected key compromise forces re-keying, because renewal would recertify the compromised key.
solid answer
~40 sBoth operations end with a new certificate: a new `serialNumber`, a new `notBefore`/`notAfter` window, a fresh issuer signature. The difference is upstream of that. **Renewal** reuses the existing key pair, so `SubjectPublicKeyInfo` is byte-identical to the old certificate's and the private key stays exactly where it already lives. **Re-keying** generates a new pair, so `SubjectPublicKeyInfo` changes, the `subjectKeyIdentifier` derived from it changes, and every place the old private key was installed needs the new one. Routine expiry is usually renewal, because it is the cheaper operation and touches nothing on the hosts. A suspected compromise forces re-keying: the holder of a copied key is covered by any certificate issued over that same public key, so renewing hands them a fresh one. Algorithm migration and a key of unknown provenance force it too.
code
pseudocode · 9 linesfunction choose_operation(subject):
// called when the current certificate is approaching notAfter
if key_compromise_suspected(subject):
return RE_KEY // new pair; also withdraw the current certificate
if key_provenance_unknown(subject):
return RE_KEY
if algorithm_being_retired(current_key(subject)):
return RE_KEY
return RENEW // same SubjectPublicKeyInfo, new serialNumber and validitygo deeper
Recall that both operations produce a brand-new certificate, and that only re-keying involves generating a new key pair.
Explain the mechanics: SubjectPublicKeyInfo is unchanged on renewal, and that is precisely why renewal is worthless once the key may have been copied.
Demonstrate the operational cost of re-keying - distribution to every replica, a new generation event for hardware-held keys - and pair it with withdrawal of the superseded certificate.
Treat re-key cost as an architectural property: if re-keying a service is a multi-day project, you have made the response to a leak expensive and people will hesitate exactly when they should not.
## Two operations that look the same from outside From a relying party's point of view, renewal and re-keying produce the same thing: a new certificate with a new `serialNumber`, a new `validity` window, and a fresh signature from the issuing authority over the `TBSCertificate`. The distinction lives entirely on the subject's side, in what happened to the key pair before the request was made. - **Renewal** - the existing key pair is kept. A new certificate is issued over the same public key. - **Re-keying** - a new key pair is generated. The new certificate is issued over the new public key, and the old private key is retired. Both are ordinary issuance from the authority's side. Neither is a repair of the old certificate: certificates are immutable once signed, so there is no such thing as editing the expiry date of one you already hold. ## What changes, and what does not | | renewal | re-keying | |---|---|---| | `SubjectPublicKeyInfo` | unchanged | new | | `subjectKeyIdentifier` | unchanged | new, since it is derived from the key | | `serialNumber` | new | new | | `notBefore` / `notAfter` | new window | new window | | `subject` name | unchanged | unchanged | | private key on the hosts | stays put | must be distributed or regenerated | | value to someone holding a copy of the old key | still usable | worthless | The last row is the whole point. A copied private key does not lose its power when a certificate expires - it loses its power when no valid certificate exists over its public half. ## Which one a compromise forces If there is credible suspicion that the private key has been copied, renewal is not a partial fix, it is an anti-fix: it extends the window in which the copy authenticates as the subject. Re-keying is mandatory, and the old certificate must additionally be withdrawn, because until it is withdrawn the copy remains usable for the remainder of the old certificate's `notAfter`. Re-keying and withdrawal are two different actions and both are needed; doing one without the other leaves an obvious gap. The same reasoning applies to a key whose provenance you cannot account for - one that arrived in an export file from a departed contractor, one that has been in an image for years, one whose generation nobody can describe. You are not asserting a breach, you are declining to certify a key you cannot vouch for. ## What re-keying costs downstream 1. **Distribution.** Every host, replica and standby that served traffic with the old key needs the new one, and the transfer itself is the most exposed moment in the key's life. 2. **Hardware-held keys.** A key that was generated inside a hardware module and cannot be exported cannot simply be copied to a new location; re-keying means a new generation event, with whatever ceremony that carries. 3. **Anything bound to the key value.** Configuration that references the public key rather than the name breaks on re-key and survives renewal. Where that binding lives in an application is its own subject. 4. **Coordination.** The new certificate and the new private key must land on a host together; landing one without the other is a self-inflicted outage. None of these costs apply to renewal, which is exactly why renewal became the default for routine expiry and why the compromise case surprises people. ## When to re-key even though nothing leaked - **Algorithm or parameter migration.** You cannot migrate to a different algorithm by renewing; a different algorithm is a different key pair by definition. - **Shortening exposure on purpose.** A long-lived key that has been through several renewals has accumulated years of opportunity to leak without anyone noticing. - **Moving storage.** Relocating a key into hardware-backed, non-exportable storage means generating it there, which is a re-key whether or not you call it one. ## The framing that keeps it straight A certificate is a statement about a key. Renewal makes the same statement again with new dates. Re-keying makes a statement about a different key. Ask which of the two is the thing you no longer trust - the dates or the key - and the choice answers itself.
- Is re-keying enough on its own after a suspected compromise?No. Re-keying gives the service a key nobody else holds, but the old certificate is still valid until its `notAfter`, so the copied key keeps authenticating as the subject until that certificate is withdrawn. The two actions address different halves of the exposure and both are required.
- Why is renewal the cheaper operation in practice?Because nothing on the hosts changes. The private key stays exactly where it is, including inside hardware storage it could never leave, so the only step is dropping in a new certificate file. Re-keying adds generation, distribution and coordination to every place the key lives.
- Does re-keying change the certificate's subject name?No. The subject name is what the authority validated and is independent of which key pair is certified. Re-keying changes the key the certificate speaks for; a name change is a different request altogether, and a certificate may be re-keyed many times while naming the same subject throughout.
saying these in an interview costs you the question
- Uses renewal and re-keying as synonyms.
- Thinks renewal extends the existing certificate's expiry date.
- Says re-keying alone fully resolves a suspected compromise.
- Believes re-keying changes the subject name in the certificate.
- Assumes a hardware-held key can be re-keyed by copying it elsewhere.