In the X.509 model, it carries a serial number, issuer, validity interval, signature algorithm, and extensions that can constrain names, purposes, policies, and certification paths.
A relying party validates the issuer’s signature and a path to an accepted trust anchor, then applies the time, name, usage, constraint, policy, algorithm, and status checks required by the application.
Key points
Binding and provenanceThe issuer signs the certificate after following its validation and approval process, allowing verifiers to detect changes and identify the authority responsible for the assertion.
Scope and constraintsExtensions can identify valid names, permitted key uses, whether the subject may issue other certificates, relevant policies, and paths to issuer or status information.
Operational useCertificates support authenticated key establishment, digital signatures, device or workload identity, document signing, code signing, and other applications when the surrounding protocol validates them correctly.
Important limitationA valid certificate does not prove that its subject is honest, safe, uncompromised, or still controls the private key. It proves only that validation succeeded under particular trust anchors, policies, evidence, and time and status assumptions.