The signature passed. Now ask which key passed it.
The robot receives a repair notice and a public key that lets the signature verify. An impostor can generate a key pair, sign a fake notice and attach its own public key. The robot needs separate evidence that the key may represent repair.example. This is the identity question left open in the signature lesson.
A certificate puts a name and public key into a verifiable statement; PKI organizes issuance, trust settings and lifecycle. Follow repair.example through X.509 fields, trust chains, time, purpose, revocation and TLS proof of private-key use. The experiment below lets you disable individual conditions and observe why valid signatures can still lead to rejection. It covers only the listed policy conditions and is not a complete PKI validator.
A valid signature under an unfamiliar key
The robot receives a repair.example notice with an attached public key, K-REAL. Verification reports PASS. That result has a defined scope: the received message and signature satisfy the chosen scheme’s verification rules under K-REAL.
An impostor can generate another pair, sign a fake notice with sk-FAKE, attach K-FAKE, and obtain the same mathematical result. Nothing has broken. Each signature matches its own key. The missing evidence is the claim that one of those keys actually belongs to repair.example.
This lesson begins exactly at that gap. A certificate does not make signatures stronger; it adds a signed identity context around a public key. PKI supplies the people, rules, software, trust settings, and lifecycle processes that let a verifier evaluate that context instead of trusting a key merely because it arrived with the message. [1][2]
Direct key checking does not scale
Two people can compare a public-key fingerprint in person. If both screens show A7:31 in our fictional example, they have a useful out-of-band check. Repeat that ritual for a bank, shop, cloud, mail, chat, and news service, however, and the verifier soon needs a different trusted meeting for every relationship.
PKI changes the shape of the problem. Rather than knowing every service directly, the verifier accepts one or more carefully managed starting points. A Certificate Authority can then sign a statement that binds a subject name to a public key, subject to its validation policy. [2]
This is delegation, not magic. The verifier still needs a reason to accept the CA, and the certificate still needs to survive name, time, purpose, chain, and status checks. The benefit is that unfamiliar keys now arrive with a path of verifiable claims instead of an unsupported label.
Open an X.509 certificate
X.509 gives certificates a common structure that software can parse. Our teaching certificate names repair.example, carries K-REAL, identifies its issuer, limits its validity period, and includes extensions such as Subject Alternative Name and Key Usage. The values are fictional; the field roles are real. [1][2]
The CA signs the TBSCertificate portion: the version, serial number, inner signature AlgorithmIdentifier, issuer, subject, validity, subject public-key information, and extensions. The outer certificate then repeats a matching signature algorithm field beside the signature value used to protect that to-be-signed data. [2]
A parser accepting the syntax is only the first gate. A perfectly encoded certificate may be expired, issued for another name, constrained to another purpose, or chained to a root the verifier has never accepted. X.509 defines how the evidence is packaged; a validation policy decides what the evidence is allowed to prove. [2]
Engineer extension: the TBSCertificate boundary includes an inner signature algorithm field
RFC 5280 places one signature AlgorithmIdentifier inside TBSCertificate, so it is covered by the CA signature. The outer Certificate structure repeats a matching signatureAlgorithm beside signatureValue. Version, serial, issuer, subject, validity, subject public-key information, and extensions are also inside the signed TBSCertificate.
Issuance checks possession and name control separately
The service first creates sk-REAL and K-REAL locally. The private key can stay behind a protected boundary while the public key goes into a Certificate Signing Request. The CA does not need the private key to issue a certificate, and sending it would defeat the purpose of local key custody. [4]
A CSR signature can demonstrate that the requester can use the private key corresponding to the public key in that request. It does not, by itself, show that the requester controls repair.example. The CA therefore performs a separate authorization or name-control check according to its policy. [4]
Only after those claims have been handled should the CA issue the certificate. Keeping the gates distinct helps diagnose failures later: a stolen account, a compromised private key, and an incorrectly validated name are different incidents even if they all produce a bad certificate outcome.
Engineer extension: a CSR is not an authorization certificate
PKCS #10 protects the request and demonstrates possession of the associated private key. The CA still needs an external process to decide whether the requested subject names and attributes are authorized under its policy.
Trust starts from a configured anchor
Following issuer signatures upward cannot continue forever. At some point the verifier reaches a public key or certificate it already treats as a trust anchor. That starting point usually entered through a controlled preload, operating-system trust store, enterprise policy, or managed update. [2]
A root certificate is often self-signed, but self-signing is not the reason it is trusted. An unknown attacker can self-sign too. The decisive fact is that the verifier's policy already accepts that key as a starting point for a particular scope. [2]
Trust-anchor management therefore deserves the same architectural attention as secret-key protection. An anchor is public, so confidentiality is not its main property. Integrity, provenance, allowed use, and controlled replacement are what stop an attacker from inserting a new starting point.
Engineer extension: a trust anchor is validation input, not necessarily another certificate in the path
RFC 5280 models the trust anchor as validation input containing a trusted issuer name, public key, algorithm, and optional constraints. Implementations often store a self-signed root certificate as a convenient container, but the trust decision comes from local configuration.
Issue downward, validate toward the anchor
Issuance usually moves down a hierarchy: a root CA certifies an intermediate CA, and the intermediate certifies repair.example. Validation walks the supplied path in the other direction until it reaches a locally accepted anchor. [2]
Why insert an intermediate? The root private key can remain offline or be used rarely, while intermediates handle routine issuance. If one intermediate is compromised, the operator can revoke and replace the affected branch without routinely exposing the root key.
That separation reduces exposure; it does not erase risk. A root-key compromise may require trust-anchor remediation across many verifiers. An intermediate compromise can still affect every certificate beneath it until status, replacement, and deployment work catch up. [2]
Turn X.509 fields into validation checks
For a TLS service, the name the client intends to reach must match an appropriate dNSName in the Subject Alternative Name extension. A certificate for evil.example cannot be accepted for repair.example merely because its signature chain is otherwise valid. Current TLS service-identity rules do not fall back to the Common Name as a substitute for SAN. [3]
The current time must fall within Not Before and Not After, and the intended operation must fit the certificate's key-use constraints. A code-signing certificate is not automatically a server-authentication credential. These checks turn fields that look descriptive into enforceable limits. [2]
CA certificates have limits too. Basic Constraints must identify the certificate as a CA, and Key Usage must permit certificate signing where that extension is present. A valid signature from a key that was not authorized to issue certificates does not create a valid certification path. [2]
Engineer extension: path building and path validation are related but different
Path building searches for a candidate route from the leaf toward an acceptable anchor. Path validation then applies signatures, constraints, name processing, policy, and other checks to a chosen path. A certificate may participate in more than one possible path.
The certificate is public; the private key proves control
An attacker can copy the real certificate because certificates are meant to be distributed. The copy still contains K-REAL and the CA's valid signature. What the copier lacks is sk-REAL, which should remain under the legitimate service's control.
In TLS 1.3, the CertificateVerify message signs a transcript of the current handshake. This binds the proof to the connection being established. The comic keeps that idea conceptual rather than presenting a reusable bare challenge-response recipe. [5]
The certificate answers which identity the public key is allowed to represent under the chain and policy. The protocol then checks whether the peer can use the matching private key now. Copying one layer does not satisfy the other, which is why a public certificate can be safely transmitted.
A certificate has a lifecycle
A certificate begins with key generation and a request, moves through issuance and use, and eventually reaches its Not After boundary. The validity window limits when a verifier may accept the certificate; it is not a promise that the private key stays safe throughout that interval. [2]
Renewal is easy to misunderstand. An operator may obtain a new certificate while reusing the existing key pair, or may rotate to a new key at the same time. A new expiry date does not prove that key material changed.
Those choices depend on policy, risk, automation, and the reason for renewal. If the key may have been compromised, simply reissuing around the same key does not remove the attacker’s copy. Lifecycle records must therefore track keys as well as certificates.
Revocation handles trouble before expiry
Suppose sk-REAL is stolen while the certificate is still inside its validity window. Time checking alone would continue to accept it. The issuer can publish an early status change through a Certificate Revocation List or an Online Certificate Status Protocol response. [2][6]
Status information is not instantaneous everywhere. An online verifier may obtain a fresh response, while an offline device may rely on a cached list that has gone stale. Products need an explicit policy for unavailable or unknown status rather than quietly treating every lookup failure as success.
OCSP good is a narrow result: the responder has not currently marked the certificate revoked. It does not say the name matches, the chain is trusted, the time is valid, or the peer controls the private key. Revocation and expiry are separate checks inside a larger decision. [6]
Engineer extension: status freshness and failure policy belong in the product design
CRL nextUpdate, OCSP producedAt/thisUpdate/nextUpdate, stapling, cache lifetime, offline operation, and fail-open or fail-closed behavior affect how quickly a compromise changes acceptance. The correct balance depends on availability requirements and threat model; an OCSP good value alone is not a complete validation result.
Connect device PKI to the HRoT
A factory can enroll device MY-017 and issue a certificate binding its identity to K-017. The matching sk-017 stays inside a protected subsystem and is exposed only through allowed operations. The certificate may travel freely; the signing capability should not. [2]
At the other end, the verifier protects the manufacturer CA public key used as its trust anchor. This asset is public but must resist unauthorized replacement. The device private key needs confidentiality and usage control; the verifier's anchor needs integrity and controlled lifecycle management.
Some designs derive or wrap device secrets using a Hardware Unique Key. That architecture can strengthen storage, but the HUK is not automatically the device signing key and should not be confused with the CA root. The exact derivation, export, reset, and recovery rules belong to the product threat model.
Engineer extension: do not collapse HUK, device identity key, and CA key into one box
A HUK may protect storage or feed a derivation hierarchy. A device identity key may be derived, generated, wrapped, or provisioned, and a manufacturer CA key usually lives in a separate issuance system. Document which asset crosses each boundary and which component is allowed to use it.
Make the PKI decision one gate at a time
Three impostors fail at different places. A self-declared fake key lacks an acceptable name and chain. A copied real certificate lacks current proof of the private key. An attacker who actually steals the real private key may pass until effective revocation, expiry, replacement, or another lifecycle response reaches the verifier.
A useful checking order starts with an accepted trust anchor, builds and validates the chain, checks name, time, purpose, and constraints, evaluates revocation status, and then verifies current private-key possession in the surrounding protocol. Implementations may organize work differently, but none of these claims should disappear behind a single green icon. [2][3][5][6]
Even a complete identity check has a boundary. It can establish evidence about who controls a credential; it does not make every statement correct or every requested action authorized. Business rules, application integrity, access control, and human judgment still decide what the system should do next.
Five ideas to take with you
- A signature verifies against a public key; a certificate supplies a signed identity context for that key.
- X.509 defines the package, while validation policy checks the chain, name, time, purpose, constraints, and status.
- A self-signed root becomes a trust anchor through controlled verifier configuration, not through self-signing alone.
- Certificates are public. The surrounding protocol must still obtain fresh evidence that the peer can use the matching private key.
- Expiry and revocation are different lifecycle controls, and device PKI must protect both private-key use and trust-anchor integrity.
Next: Secure Boot. We will place a trusted public key at reset and follow how each software stage earns the right to run.
References
- ITU-T X.509 (10/2019), Information technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks: The certificate and certification-path framework behind X.509.
- RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile: Certificate fields, extensions, path validation, trust anchors, and CRLs.
- RFC 9525, Service Identity in TLS: Current DNS service-identity matching uses subjectAltName identifiers rather than Common Name fallback.
- RFC 2986, PKCS #10: Certification Request Syntax Specification: The structure and signature of a certificate signing request.
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: CertificateVerify signs the current TLS handshake transcript.
- RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP: OCSP response states including good, revoked, and unknown, plus the limits of a good response.
Which checks must a certificate pass?
Begin with every condition satisfied. Keep the chain signatures valid but disable the SAN name match, then step through validation. Valid signatures cannot authorize the wrong service name. Reset, disable private-key possession and compare the two rejection reasons.
This teaching model has six policy checks supplied by you. It does not parse X.509, verify actual certificate signatures, handle revocation or implement all path constraints. It is not a browser or production PKI validator.
Learning guide
Security Foundations
Open the course outline → · Progress counts published lessons only
Prerequisites
- Understand private-key signing and public-key verification
What I learned
- Explain why a valid signature does not identify an unfamiliar public key
- Read the main fields and signed boundary of an X.509 certificate
- Follow a certificate chain to a configured trust anchor
- Separate name, time, purpose, revocation, and private-key checks
- Connect device PKI to HRoT without confusing HUK and identity keys