skip to content

A server's private key file and its certificate are both committed to a public repository - which disclosure matters, and why?

level: juniorimportance: must knowfreq 68%

answer

  1. one half is broadcast, one never moves
  2. the certificate is not secret material
  3. possession is the authority, not the document
  4. a new certificate over the same key helps nobody
  5. re-key, then withdraw the old certificate

basics

~20 s

Only the private key matters. An end-entity certificate is handed to every client that connects, so publishing it costs essentially nothing; the private key is the one secret that proves a server is entitled to use that certificate.

solid answer

~50 s

A certificate is a signed public statement: it carries the subject name, a `validity` window of `notBefore` and `notAfter`, and the public half of the key pair in `SubjectPublicKeyInfo`. The server sends that whole structure to every client that opens a connection, so a copy in a public repository tells an attacker essentially nothing new - at most it discloses an internal name. The private half never appears in the certificate and never travels; it is what the server uses to prove it is the subject the certificate describes. Anyone who copies it can authenticate as that name until the certificate is withdrawn or reaches `notAfter`, and nothing in the certificate records that this happened. The fix is re-keying: a fresh key pair, a certificate issued over the new public key, and the old certificate taken out of service. Reissuing over the same key changes nothing.

go deeper

for a junior

Recall which half of the pair travels in the certificate and which never leaves the host, and that only the second one leaking is an incident.

for a middle

Explain why a passphrase on a key file is not a login: no attempt counter exists, so guessing runs offline at whatever rate the attacker's hardware allows.

for a senior

Show the response in order - assume permanence, generate a fresh pair where it will be used, certify the new public key, withdraw the old certificate, hunt every copy.

for a principal

Frame it as a design constraint: build so that replacing a key is routine, because a key you cannot cheaply replace turns one careless commit into an outage you must schedule.

## The two halves, and which one is in the certificate A key pair is two values that belong together. An end-entity certificate - the one a server presents when a client connects - carries only the public half, inside the `SubjectPublicKeyInfo` field, alongside the `subject` name it is claiming, the `issuer` that vouched for it, a `serialNumber`, and a `validity` window given as `notBefore` and `notAfter`. The issuing authority signs that whole body, the `TBSCertificate`, so nobody can change a field without breaking the signature. The private half is not in the certificate and is not sent anywhere. It sits in a file on the host, or inside a hardware module. During a connection the server performs an operation that only the holder of that private value can perform, and the client checks it against the public value in the certificate. That single step is what turns a public document into a claim about **this** machine. ## Why publishing the certificate costs essentially nothing - It is **broadcast by design**. Every client that has ever connected already holds the same bytes. - It is **self-protecting**. The issuer's signature covers the whole `TBSCertificate`, so a copy cannot be edited into a certificate for a different name. - It is **useless alone**. Presenting a certificate you cannot back with the matching private key fails at the moment the peer asks for proof. - The one real cost is **disclosure of content**: an internal certificate may name hosts, an organisation, or a validity window you would rather not publish. That is an information leak, not a break. ## Why publishing the private key is total | disclosed | what the holder can do | what the holder cannot do | |---|---|---| | the end-entity certificate | read the subject name, the public key, the validity window, the issuer | authenticate as that subject | | the private key, unencrypted | authenticate as that subject anywhere, for the rest of the validity window | alter the certificate's fields | | the private key, passphrase-protected | the same, after offline guessing bounded only by the derivation cost | anything further | The last row is the one candidates get wrong. A passphrase on a key file is not a login: there is no server to count failed attempts and no lockout. An attacker with the file guesses at whatever rate their hardware allows, and the only brake is how expensive the key-derivation step is. A passphrase buys time; it does not change the verdict that the key must be treated as compromised. ## What actually repairs it 1. **Assume the copy is permanent.** Deleting the commit removes it from the current tree, not from clones, caches or anyone who already fetched it. 2. **Generate a new key pair** where the key will be used, so the new private value is never written anywhere it does not need to be. 3. **Obtain a certificate over the new public key.** This is re-keying. Reissuing over the same public key - renewal - hands the leak-holder a fresh certificate too. 4. **Have the old certificate withdrawn.** Publishing that withdrawal, and making relying parties act on it, is a separate mechanism with its own delivery problems. 5. **Replace every copy** of the old key: other nodes in the fleet, images, backups, and any export file made while moving it. ## The asymmetry worth remembering Every other control in this area is a check some relying party performs on a signed statement: does the path reach an anchor, does the name match, has the certificate expired, was it published where mis-issuance would be visible. None of those checks can distinguish the legitimate holder of a private key from someone who copied it, because the two are doing identical arithmetic with identical inputs. That is why a leaked private key is not one more finding on a list - it silently voids the conclusions every other control was designed to support, and only replacing the key restores them.

  • The key file was encrypted with a passphrase before it was committed. Does that change the answer?
    It buys time, not safety. There is no service counting attempts, so the attacker guesses offline at full speed and the only brake is the cost of the key-derivation step. Treat the key as compromised and re-key; if the passphrase was long and random you may have hours or weeks rather than minutes, which is scheduling relief, not a reprieve.
  • The same key pair was reused for a certificate on a second hostname. What is the blast radius?
    Both certificates speak for the same private key, so the copy authenticates as both names. Re-keying one and leaving the other is a half fix: every certificate issued over that public key has to be replaced with one over a new key pair, and each old certificate withdrawn separately.
  • Does it matter whether the leaked key belonged to a server or to an issuing authority?
    Enormously. A server key impersonates one subject until that certificate is withdrawn or expires. An issuing authority's signing key produces certificates for any name it is permitted to certify, each one indistinguishable from legitimate issuance, so the damage is bounded by the authority's scope rather than by one name.

The certificate is a letter of introduction, written to be shown to everyone. The private key is your proof that you are the person the letter describes - hand that over and the letter introduces the new holder just as convincingly.

saying these in an interview costs you the question

  • Thinks the certificate itself is confidential material.
  • Says reissuing over the same key pair fixes the leak.
  • Believes a passphrase on a key file prevents offline guessing.
  • Assumes deleting the commit removes the exposure.
  • Waits for the certificate to expire instead of re-keying.