skip to content

A certification request asks for extensions, yet the issued certificate carries different values: why is the authority's profile what decides?

level: seniorimportance: should knowfreq 42%

answer

  1. an application, never an instruction
  2. the profile filters what was asked
  3. only validated names survive
  4. serial and validity are not requestable
  5. silent narrowing, discovered by traffic

basics

~20 s

The extensionRequest attribute is an application, not an instruction. The issuing authority applies its own certificate profile, keeping only names it validated, fixing usage extensions to its own values and choosing serial number and validity itself.

solid answer

~50 s

Everything in a `CertificationRequest` is a request. The `extensionRequest attribute` is where the applicant asks for extensions, and the authority is free to grant, alter or drop each one according to the **certificate profile** for the class of certificate it is issuing. In practice it keeps only the requested names it actually validated, sets usage-constraining extensions to the profile's fixed values whatever was asked, refuses anything a subscriber certificate may not carry, and chooses the serial number, issuer and validity window itself — none of which the request can express. The operational consequence is that a deployment which assumes what it asked for is what it got will break late: a silently dropped name works everywhere except on the one host that needed it, and only when traffic for that name arrives. Read the issued certificate back before deploying.

code

pseudocode · 17 lines
pseudocode
apply_profile(request, validated_names):
    issued_names <- empty
    for each name in request.extensionRequest.subjectAltName:
        if name is in validated_names:
            add name to issued_names
        else:
            drop the name and continue      // no error is raised to the applicant

    if issued_names is empty:
        reject the request

    if the request asks for issuing capability:
        drop that ask                       // a subscriber profile never grants it

    set usage-constraining extensions from the profile, ignoring the request
    set serial number, issuer and validity window from the profile
    sign and return the certificate

go deeper

for a junior

The thing to remember is that you ask, and the authority decides. What comes back may cover fewer names than you requested, so look at the certificate you received rather than the request you sent.

for a middle

Explain the split: the extensionRequest attribute carries the ask, the issuance profile decides the result, and serial number, issuer and validity have no field in a request at all.

for a senior

Bring the failure mode: a silently dropped name deploys cleanly, passes a health check on another name, and fails when traffic for the missing one arrives. Show the read-back comparison you make part of issuance.

for a principal

The design point is accountability: an authority signs only what it can defend at audit, so requester control is deliberately limited. Decide where in your estate that read-back check is enforced, since no one downstream will catch it.

## A request is an application, not an instruction The `extensionRequest attribute` inside `CertificationRequestInfo` is the only place an applicant can ask for extensions, and its name is honest: it is a **request**. The certificate that comes back is the authority's own statement, signed with the authority's own key, and an authority puts its name only to things it is prepared to defend. Every field of the result is therefore chosen by the **certificate profile** for the class of certificate being issued. This is one of the most reliable sources of surprise in production, because the failure is silent. There is no error. Issuance succeeds, a valid certificate arrives, and what is missing from it is discovered later, by traffic. ## What the profile decides 1. **Which requested names survive.** The authority keeps the requested `dNSName` entries it validated and drops the rest. A request naming four hosts where validation succeeded for three yields a certificate for three. 2. **The usage-constraining extensions.** Extensions that limit what the certificate may be used for are set from the profile, not copied from the request. Asking for a broader set does not widen them. 3. **Capability the profile forbids.** A request that asks to be an issuing authority — `basicConstraints` with `cA` set — is not granted by a subscriber profile. That ask is dropped, and an authority may reject the request outright for making it. 4. **The identifiers the applicant cannot express.** The serial number, the issuer name and the `notBefore`/`notAfter` window have no field in a certification request at all. They come from the profile every time. | Asked for in the request | What the issued certificate carries | |---|---| | a `subject` distinguished name | what the profile permits at that validation level | | requested `dNSName` entries | only the entries the authority validated | | usage-constraining extensions | the profile's fixed values for that class | | issuing capability | dropped by a subscriber profile | | a desired validity window | the profile's window; not requestable | | a serial number | chosen by the authority; not requestable | ## Why it is built this way An authority is accountable for every certificate under its key, and it is audited against rules about what those certificates may contain. If a requester could dictate the contents, the audit would be meaningless: anyone who could pass name validation could mint a certificate claiming issuing capability, or a decade-long lifetime, or usage the rules forbid. The profile is where the authority's obligations are turned into a filter over requests. **The request says what the applicant wants; the profile says what the authority is willing to state.** A second reason is that the applicant is not in a position to know some of it. Serial numbers must be unpredictable and unique within the authority. Lifetimes are governed by rules that change over time, downwards. Neither belongs in the hands of the party being certified. ## The failure mode this produces Consider a fiscal receipt service for taxi meters, where one certificate is meant to cover both the meter-facing endpoint and the endpoint the revenue authority collects from. Both names go into one request under the `extensionRequest attribute`. Validation succeeds for the first name and fails quietly for the second, because its zone is managed by a different team. The authority issues a valid certificate for one name. Deployment succeeds. Health checks, which hit the meter-facing name, pass. The defect surfaces at the end of the reporting period, when the revenue authority's collector connects to the second name and its client refuses the certificate, because the name it asked for is not in the certificate it was given. Nothing failed at issuance, at deployment or in monitoring — the certificate was never wrong, it was merely narrower than assumed. ## What to do about it - **Read back the issued certificate and compare it with the request** before anything deploys. The comparison is the check; the absence of an error is not. - **Make the comparison automatic.** Treat a missing requested name as a failed issuance in whatever process obtains the certificate, rather than relying on someone reading the result. - **Probe every name the certificate is supposed to cover**, not just the one a health check happens to use. A certificate that covers three names out of four passes three quarters of the naive checks. - **Expect usage extensions to come back as the profile's**, and do not build anything on the assumption that a requested value was honoured. - **Treat a rejected ask as information.** A profile that refuses part of a request is telling you the class of certificate you asked for is not the class you wanted. The general principle worth stating in an interview: in issuance, the applicant controls the key and the ask, and the authority controls the statement. Every operational habit that survives contact with production follows from taking that seriously.

  • The issued certificate is missing one of the requested names and nothing reported an error. How do you catch that before deployment?
    By comparing the issued certificate against the request as a step in whatever obtains it, and failing that step when a requested name is absent. Then probe every name the certificate is supposed to cover, not just the one a health check uses. Absence of an error at issuance means only that the authority was willing to sign something — not that it signed what you asked for.
  • A request asks for issuing capability so the team can sign internal certificates. What happens?
    A subscriber profile will not grant it: the ask is dropped and the authority may reject the request outright for making it. Issuing capability is what makes a certificate an authority, and granting it to a subscriber would put every name in the world under that key. If you need to issue internally, you are asking for a different class of certificate from a different process, not for an extension on this one.
  • Why can the applicant not request a serial number or a validity window?
    Because neither is the applicant's to choose and neither has a field in a certification request. The serial must be unique and unpredictable within the issuing authority, which only the authority can guarantee, and lifetimes are governed by rules the authority is audited against and which tighten over time. Both are set from the profile at signing time, on every certificate.

saying these in an interview costs you the question

  • Assumes the issued certificate mirrors the requested extensions.
  • Thinks a name dropped at issuance causes a visible error.
  • Says the applicant sets the validity window in the request.
  • Believes asking for issuing capability grants it.
  • Treats successful issuance as proof the request was honoured.
  • Checks one host name and calls the certificate verified.