skip to content

A PKCS#10 request is signed with the very key being certified: what does that self-signature prove, and what does it not?

level: middleimportance: should knowfreq 45%

answer

  1. the check is deliberately self-referential
  2. it closes one hole, completely
  3. control of the key, not of the name
  4. point-in-time, not exclusivity
  5. name validation is a separate investigation

basics

~20 s

It proves the requester controlled the matching private key at the moment of signing, which stops anyone certifying a public key they cannot use. It proves nothing about entitlement to the requested name, nothing about identity, and nothing about later.

solid answer

~40 s

The outer `CertificationRequest` signature is verified with the public key sitting inside `subjectPKInfo` in the same request, so the check is deliberately self-referential. It is **proof of possession**: it demonstrates that whoever assembled the request held the private half of the key pair when they signed. That closes exactly one hole — copying somebody else's public key into your own request and having a certificate issued for a key you cannot use. It is not a trust decision and not an identity check: any applicant can generate a pair and produce a request that verifies. Entitlement to the `subject` name and to any requested `subjectAltName` entries is established by a completely separate validation process, and the demonstration is point-in-time — it says nothing about whether the key is still exclusively held tomorrow.

code

pseudocode · 14 lines
pseudocode
on receiving a certification request:
    parse certificationRequestInfo
    verify the outer signature using certificationRequestInfo.subjectPKInfo
    if verification fails:
        reject                      // the requester does not hold the private key

    // signature verified: the requester controlled that private key just now.
    // it establishes nothing about the names below, so check them separately.

    for each requested name in subject and extensionRequest subjectAltName:
        if not validated(name, required level):
            drop or reject the name

    apply the issuance profile and sign

go deeper

for a junior

The takeaway is that you sign your own request with the key you are asking to have certified, and that this only shows the key is yours to use. It does not ask for or grant any name.

for a middle

Explain that the signature is verified with the public key inside the same request, so the check is self-referential by design, and name the separate validation process that establishes entitlement to the name.

for a senior

Show that you know what the check cannot see: exclusivity, key custody, and anything after the moment of signing. That is why lifetimes are bounded and why a compromised key is a withdrawal question, not a validation one.

for a principal

The design point worth arguing is that issuance deliberately splits two unrelated proofs. Anywhere your estate merges them — a system that treats holding a key as authorisation to be named — you have rebuilt the hole this check exists to close.

## A signature that verifies against itself The outer `CertificationRequest` carries a signature computed over the encoded `CertificationRequestInfo`, made with the private key of the pair being submitted for certification. The authority verifies that signature using the public key it finds inside that same request, in `subjectPKInfo`. Nothing external is consulted, and that is not an oversight: the check is meant to be self-referential. This is called **proof of possession**. Read literally, it says: the party who assembled these bytes was able to produce a signature that this public key verifies, therefore they held the corresponding private key at that moment. ## What it actually rules out Without the check, an applicant could lift a public key out of anyone's published certificate and submit it in a request under a name they had validated. The authority would then sign a certificate binding somebody else's key to the applicant's name. The applicant could not use that certificate — they cannot sign or decrypt with a key they do not hold — but the resulting binding is still a false statement in circulation, and confusion about *which party a signature made with that key represents* is exactly the kind of ambiguity a certificate exists to remove. So proof of possession closes one hole and it closes it completely: **every certified key is a key the applicant could demonstrate control of.** ## What it does not prove - **Not entitlement to the name.** Nothing about holding a key says anything about the `subject` distinguished name or the requested `dNSName` entries. A request for a name you have no connection to verifies exactly as well as a request for your own. - **Not identity.** No person and no organisation is established. The signature is made by whoever ran the operation, which may be an operator, a build job, or an attacker inside either. - **Not exclusivity.** It proves someone had the key, not that only they had it. A key copied out of a backup produces requests that verify perfectly. - **Not durability.** It is a point-in-time demonstration. A key that leaks the day after issuance leaves a certificate that verified proof of possession and is now worthless as evidence of who holds it. - **Not protection quality.** Where the key was generated and how it is stored is invisible to the check. ## Where the missing checks actually live The authority runs **two independent investigations**, and keeping them apart is the whole model: 1. **May this key be certified at all?** Answered by the self-signature on the request. 2. **May this applicant be named this?** Answered by the authority's validation process for the class of certificate, which is unrelated to the key and reaches out to the world — to the name itself, to registries, or to both. A certificate is the join of those two answers. Either one alone is close to worthless: a validated name with an unverified key binds a name to a key nobody proved they hold, and a proven key with no name validation is a self-signed certificate wearing an authority's signature. | Question | Answered by | Scope of the answer | |---|---|---| | Does the applicant hold this private key? | outer signature on the request | this key, at signing time | | May the applicant be named this? | the authority's validation process | this name, at validation time | | Will both still be true next month? | neither | nothing, which is why lifetimes are bounded | ## The lifecycle consequence The same idea reappears at the other end of a certificate's life. Because control of a private key is demonstrable, it is one of the things an issuing authority accepts as grounds for a **withdrawal request** from someone other than the original applicant: a party who can demonstrate possession of the certified key has demonstrated something the authority can check, even when they are not the subscriber of record. That is an authority question — who may ask — rather than a mechanism question, and the mechanisms by which a withdrawn certificate is published are a separate subject. ## How to say this in an interview State the positive and the negative in one breath: *the self-signature proves control of the private key at signing time and nothing else; the name is established by a separate validation process, and neither answer keeps holding, which is why certificates expire.* Candidates who stop after the positive half typically also believe that a certification request somehow authorises the name inside it.

  • Why does an authority bother with proof of possession when it already validates the name?
    Because the two answer unrelated questions. Name validation says who may be named; it says nothing about which key should be bound to that name. Without proof of possession, an applicant could submit somebody else's public key under a validated name, and the authority would sign a true-looking statement binding a key to a party that cannot use it — an ambiguity about who a signature made with that key represents.
  • Who is entitled to ask an issuing authority to withdraw a certificate?
    Three parties, for three different reasons. The subscriber of record, authenticated the way the authority authenticates that account. Anyone who can demonstrate possession of the certified private key, which is why key-compromise reports are accepted when they carry that demonstration. And the authority itself, acting on its own findings — mis-issuance, a failed validation discovered afterwards, or a policy violation. Which is a question of authority; the publication mechanisms are a separate subject.
  • Does a verified proof of possession tell you the key was generated safely?
    No. The check sees one signature and the public key that verifies it. It cannot distinguish a key generated with good randomness in protected storage from one generated weakly and copied across three machines. Key generation, algorithm choice and custody are a separate concern, and nothing in the certification request exposes them to the authority.

Signing the request with the key you are asking to have certified is like filling in an application in the handwriting you want registered: it shows the pen is yours. Whether you are entitled to the name you wrote on the form is checked by a different act entirely.

saying these in an interview costs you the question

  • Says the self-signature proves the requester owns the name.
  • Treats a verifying request as a trust decision by itself.
  • Thinks proof of possession shows the key is exclusively held.
  • Believes the authority's validation replaces the possession check.
  • Assumes the check says something about how the key is stored.
  • Calls the request self-signed and therefore untrustworthy overall.