In any X.509 certificate, leaf or CA, which fields make up the signed TBSCertificate and what does it bind?
answer
- one signed body, two outer parts
- names, a key, and a window
- issuer picks the serial number
- SubjectPublicKeyInfo is the payload
- extensions only exist from v3
basics
~10 sThe TBSCertificate holds version, serialNumber, signature, issuer, validity as notBefore and notAfter, subject and SubjectPublicKeyInfo, plus v3 extensions. Signed as one unit, it binds that public key to those names for that window.
solid answer
~40 sA certificate is three parts: a `TBSCertificate` body, a `signatureAlgorithm`, and a `signatureValue` computed over the DER encoding of that body. The body carries `version` (which holds 2 for a v3 certificate), a `serialNumber` the issuer assigns, a `signature` `AlgorithmIdentifier`, the `issuer` name, `validity` as `notBefore` and `notAfter`, the `subject` name, and `SubjectPublicKeyInfo` — the public key together with its own `AlgorithmIdentifier`. Everything else is in the v3 extension block. Because the issuer signs the whole body as one blob, the assertion is narrow and precise: this issuer states that this public key belongs to this named subject between these two instants. It says nothing about who holds the matching private key today, and nothing about whether you should trust the issuer.
code
json · 27 lines{
"tbsCertificate": {
"version": 2,
"serialNumber": "04:9f:1c:6b:2a:e0:77:31",
"signature": "sha256WithRSAEncryption",
"issuer": "C=EX, O=Example Public CA, CN=Example Public CA G3",
"validity": {
"notBefore": "2026-09-01T00:00:00Z",
"notAfter": "2026-11-30T23:59:59Z"
},
"subject": "CN=shop.example.test",
"subjectPublicKeyInfo": {
"algorithm": "rsaEncryption",
"keyBits": 2048
},
"extensions": [
"subjectAltName",
"keyUsage",
"extKeyUsage",
"basicConstraints",
"authorityKeyIdentifier",
"subjectKeyIdentifier"
]
},
"signatureAlgorithm": "sha256WithRSAEncryption",
"signatureValue": "<covers the DER encoding of tbsCertificate>"
}go deeper
Be able to list the body fields from memory and say what the structure binds: a public key to a name, for a window, asserted by an issuer. Knowing the private key is not in there is half the question.
Explain the split between the signed body and the outer signature, why the algorithm appears twice, and why extensions rather than the subject line carry the meaning of a modern certificate.
Show what the assertion does not cover — current key possession, issuer diligence, acceptability to your own trust set — and what that means for a system ingesting certificates it did not create.
Frame the certificate as a third-party claim with a fixed shape and a chosen lifetime, and reason about what your organisation is willing to accept on the strength of one.
An X.509 certificate is a signed statement, and almost every practical question about one reduces to two smaller questions: which bytes were signed, and what do those bytes actually claim? ## Three parts, one of them signed The outer structure has exactly three members: 1. `tbsCertificate` — the **to-be-signed** body, which holds every field a reader cares about. 2. `signatureAlgorithm` — an `AlgorithmIdentifier` naming the algorithm the issuer used. 3. `signatureValue` — the issuer's signature, computed over the **DER encoding of the body**. The signature therefore does not cover itself, and it does not cover the outer `signatureAlgorithm` either. That is why the body carries its own `signature` field, also an `AlgorithmIdentifier`: **RFC 5280** requires the two to hold the same value, and the inner copy sits inside the signed bytes. Anyone rewriting the outer one to claim a different algorithm breaks the signature, which is the point of the duplication that looks redundant at first reading. ## What each TBSCertificate field is for | Field | Contents | Why it is load-bearing | |---|---|---| | `version` | `2` for a v3 certificate | Only v3 carries an extension block; a v1 certificate (`0`) has none at all | | `serialNumber` | A positive integer the issuer assigns | Unique per issuer, so `issuer` plus `serialNumber` names exactly one certificate | | `signature` | An `AlgorithmIdentifier` | Pins the signing algorithm **inside** the signed bytes | | `issuer` | The distinguished name of the signing authority | States whose key is supposed to verify the `signatureValue` | | `validity` | `notBefore` and `notAfter` | The window the issuer intends the binding to hold | | `subject` | The distinguished name of the holder | Descriptive naming only; a server identity belongs in `subjectAltName` | | `subjectPublicKeyInfo` | The public key plus its own `AlgorithmIdentifier` | The object actually being bound to a name | Two of these regularly surprise people. `subject` is a directory-style name (organisation, country, common name) and is allowed to be **empty**, in which case the issuer puts the identity in `subjectAltName` and marks that extension critical. And `serialNumber` is not a counter you can assume is small: the profile expects readers to handle values up to 20 octets, so a database column sized for a 64-bit integer will eventually reject a perfectly ordinary certificate. ## The v3 extension block Everything modern lives here. Each extension is an OID, a boolean `critical` flag, and an encoded value. They fall into four rough families: - **Identity** — `subjectAltName`, which carries the names a peer is actually matched against, as `GeneralName` choices such as `dNSName` and `iPAddress`. - **Constraints** — `keyUsage` with bits like `digitalSignature`, `keyEncipherment`, `keyCertSign` and `cRLSign`; `extKeyUsage` with purposes such as `id-kp-serverAuth` and `id-kp-clientAuth`; `basicConstraints` with its `cA` boolean and `pathLenConstraint`; and `nameConstraints` on an authority. - **Identifiers** — `authorityKeyIdentifier` and `subjectKeyIdentifier`, hints that help a reader work out which key is which. - **Pointers** — `authorityInfoAccess` with `id-ad-caIssuers` and `id-ad-ocsp`, plus `cRLDistributionPoints` and `freshestCRL`: URLs written into the certificate at issuance. ## What the binding asserts, and what it does not Read as a claim, a certificate says: *the issuer named in `issuer` asserts that the key in `SubjectPublicKeyInfo` belongs to the subject named here, for the window in `validity`, subject to the constraints in the extensions.* Everything a beginner tends to add to that is absent: - It does **not** contain the private key. A certificate is a public document, safe to publish, and a monitor collects millions of them. - It does **not** prove the holder still controls that private key — only that the issuer was willing to say so when it signed. - It does **not** say the issuer checked anything in particular; what an authority verified before signing is an issuance question, not a field. - It does **not** update. A certificate is a snapshot; a name change, a key change or a withdrawal all need something outside the structure. - It does **not** tell you the certificate is acceptable **to you**. That depends on whether you trust the issuer at all, which is a property of your own anchor list, not of these bytes. ## Reading one you did not create A monitor that ingests certificates issued for names in a zone it administers never created any of them, and that is the useful frame for a junior candidate. Every field is an assertion by a third party, written at one moment. `subject` is whatever the issuer decided to write; `validity` is whatever window it chose; the pointers are whatever URLs it embedded. The structure is rigid and machine-checkable, and the meaning is entirely a matter of who signed it and whether that signature holds — which is why the first thing to be clear about is which bytes the signature covers.
- Why does a certificate name the signature algorithm twice?The outer `signatureAlgorithm` is not covered by the signature, so it could be rewritten in transit. The `signature` field inside `TBSCertificate` is covered, and RFC 5280 requires the two to match, so a reader can detect the substitution: changing the inner copy invalidates the signature.
- A certificate your monitor ingests has an empty subject field. Is that legal?Yes. When the subject is an empty sequence, the issuing CA must include `subjectAltName` and mark it critical. The identity then lives entirely in that extension, which is where a verifier reads it from in any case.
- What does the validity window actually guarantee at the moment you read the certificate?Only that the issuer intended the binding to hold between `notBefore` and `notAfter`. Whether it holds now is a comparison against the reader's own clock, and expiry is not the same as withdrawal — a certificate can be perfectly unexpired and no longer good.
A signed letter of introduction: the writer vouches for the bearer's name, the letter is dated, and you can check the handwriting without phoning the writer. It says nothing about whether the bearer is still the person carrying it.
saying these in an interview costs you the question
- Thinks the certificate contains the private key as well as the public one
- Says the signature covers the whole certificate including the signatureValue
- Treats a certificate that parses and has not expired as therefore trusted
- Calls the extension block optional decoration around the real subject line
- Reads version 3 as the third certificate issued for that name