What does a PKCS#10 certification request send to a certificate authority, and what stays behind with the applicant?
answer
- one half of the pair travels
- an application, not yet a certificate
- subject, public key, attributes
- extensionRequest is where names are asked for
- outer signature made by the applicant
basics
~10 sA PKCS#10 certification request carries the subject name being asked for, the public key and any requested extensions, all self-signed with the matching private key. The private key is not sent to the authority.
solid answer
~40 sA PKCS#10 certification request is an application, not a certificate. Its inner `CertificationRequestInfo` holds a `version`, the `subject` distinguished name being asked for, the public key in `subjectPKInfo`, and an `attributes` set whose `extensionRequest attribute` is where extensions such as a `subjectAltName` with `dNSName` entries are requested. The outer `CertificationRequest` wraps that with a signature made using the private key of the very pair being certified, which is the proof of possession. The private key is never sent and does not need to leave the machine that generated it. What comes back is a different object: a certificate signed with the authority's own key, whose serial number, validity window and final extension values the authority chose.
code
pseudocode · 14 linesCertificationRequest
certificationRequestInfo
version 0
subject the distinguished name being asked for
subjectPKInfo
algorithm identifier of the public key algorithm
publicKey the public half of the generated pair
attributes
extensionRequest
subjectAltName
dNSName first requested host name
dNSName second requested host name
signatureAlgorithm identifier of the signing algorithm
signature made with the private half, over certificationRequestInfogo deeper
Remember the split: the public key and the requested name travel inside the request, the private key does not. And remember the request is an application, while the certificate that comes back is signed by somebody else.
Be able to walk the two layers by name: CertificationRequestInfo with version, subject, subjectPKInfo and attributes, wrapped by a CertificationRequest whose signature is made with the private key being certified.
Show that you treat the issued certificate as the source of truth rather than the request. Read it back after issuance, because the authority chose the serial, the validity window and which requested extensions survived.
The lever here is that the applicant controls the key and the authority controls the statement. Where your estate's requests are generated, and who can produce one for a name, is an access-control question before it is a cryptography question.
## The request is not a certificate A **PKCS#10 certification request** (RFC 2986) is the message an applicant sends to a certificate authority to say: here is a name I want, here is the public key I want bound to it, please sign a statement to that effect. It is not itself a certificate and nothing trusts it. It carries no issuer, no serial number and no validity window, because those are not the applicant's to choose. What comes back from the authority is a separate object signed with the authority's **own** signing key. Keeping those two objects apart is the whole of this question. A candidate who calls the request *the certificate* because it is signed has missed which key made the signature and what that signature is for. ## Which half of the key pair travels Before a request can exist, the applicant generates a key pair. The halves go different ways: - The **private key** is not sent to the authority. It stays with the applicant, and an authority that asks for it is asking for something the issuance model does not require. - The **public key** travels inside the request, in the `subjectPKInfo` field — the same `SubjectPublicKeyInfo` structure that will appear in the issued certificate. That asymmetry is the point of the whole exercise: the authority is being asked to make a public statement about a key it can see, on behalf of someone who can prove they hold the half it cannot see. ## Inside CertificationRequestInfo The request has two layers. The inner layer, `CertificationRequestInfo`, is the part that gets signed, and it has four fields: 1. `version` — the format version, which is `0` for the structure in use. 2. `subject` — the distinguished name the applicant is asking to have certified. 3. `subjectPKInfo` — the public key together with its algorithm identifier. 4. `attributes` — a set of additional asks, the important one being the `extensionRequest attribute`, which is where a requester asks for certificate extensions. A request for several host names is made here, as a requested `subjectAltName` carrying one `dNSName` entry per name. | Part of the request | Supplied by | What it means | |---|---|---| | `subject` | applicant | the name being asked for, not the name granted | | `subjectPKInfo` | applicant | the public key to be bound | | `extensionRequest attribute` | applicant | requested extensions, including requested names | | outer signature | applicant's private key | proof the applicant holds the private half | | serial number, validity, issuer | authority | chosen at signing time, never requested | ## The outer signature The outer `CertificationRequest` wraps `CertificationRequestInfo` with a signature algorithm identifier and a signature computed over the encoded inner structure, using the private key of the pair being certified. The authority verifies that signature with the public key it finds in `subjectPKInfo` — the check is self-referential on purpose. It demonstrates that whoever assembled the request controlled the matching private key at the time of signing. It is not a trust decision: any applicant can generate a key pair and produce a request that verifies. ## What the authority does with it 1. **Verify the outer signature** against the public key in the request. A request that fails here is rejected outright. 2. **Validate the names independently.** Nothing in the request establishes that the applicant is entitled to the name in `subject` or in the requested `subjectAltName`; the authority runs its own validation process for the class of certificate being issued. 3. **Apply its issuance profile.** The authority sets the serial number, the validity window and the issuer, and decides which of the requested extensions survive and with which values. 4. **Sign**, with the authority's own key, producing a certificate that binds the submitted public key to the names the authority was willing to vouch for. ## Why this shape matters in practice - The certificate that comes back is bound to **that** key pair. A different key pair needs a different request. - Because the requested name and the granted name are separate things, you read back the issued certificate rather than assuming it mirrors your request. - The signature on the request and the signature on the certificate are made by different parties with different keys, and confusing them is the most common way this material is misremembered. - The applicant chooses the key; the authority chooses everything about the statement it makes.
- The applicant asked for a certificate valid for three years. Why can that not be expressed in the request?Because validity is not the applicant's field. `CertificationRequestInfo` has no validity window at all: `notBefore` and `notAfter` are set by the issuing authority when it signs, from its own profile. The same is true of the serial number and the issuer name. A request expresses what the applicant wants bound; the certificate expresses what the authority was willing to state, and for how long it is prepared to stand behind it.
- Two services need certificates and the team generates one key pair for both. What does that change about the requests?Nothing structurally — each request still carries that same public key in `subjectPKInfo` and is signed with the same private key — but it collapses two failures into one. Both certificates then speak for a single private key, so a compromise of it affects both services at once, and replacing the key means replacing both certificates. Whether that is acceptable is a key-custody decision, not something the request format constrains.
- Does the authority need the request at all once it has validated the name?Yes, because the request is the only place the public key being certified arrives, and the only place the applicant demonstrates it holds the matching private key. Name validation answers a different question — who may be named — and answers nothing about which key should be bound to that name. An authority that signed a name without a verified request would be free to bind any key at all to it.
saying these in an interview costs you the question
- Says the private key is sent to the authority inside the request.
- Calls the certification request a certificate because it is signed.
- Assumes the issued certificate simply mirrors the requested fields.
- Thinks the request proves the applicant is entitled to the name.
- Cannot say which half of the key pair the request carries.
- Believes the applicant picks the serial number and validity window.