6 Certificates and Public Key Infrastructure
Learn how digital certificates bind identities to public keys, how PKI issues and manages certificates, and how trust chains and validation support authentication.
What a establishes
A is a digitally signed record that binds an identity or name to a public key. In common X.509 certificates, fields include the subject, issuer, public key, validity period, and extensions describing permitted uses. For example, a website certificate can associate the DNS name shop.example with a public key.
The certificate’s signature lets a verifier check that the record was issued by the named issuer and has not been altered. A certificate does not make its subject inherently trustworthy: it provides a signed identity-to-key binding that a relying party evaluates under its own trust rules. Nor does a certificate alone encrypt a connection. In HTTPS, it helps authenticate the server, while the TLS protocol establishes keys for protecting the connection.
PKI and certificate issuance
A consists of the people, policies, procedures, and technology used to create, issue, manage, validate, and revoke certificates and keys. A signs certificates and manages their lifecycle. A registration authority (RA) may perform enrollment or identity checks on a CA’s behalf, but the CA remains responsible for issuance.
A typical certificate issuance process follows these steps:
An applicant generates a key pair and submits a certificate request containing a public key and requested identity.
The CA or RA checks the applicant’s identity or control of the named resource, according to the certificate type and applicable policy.
The CA creates and signs the certificate, binding the checked name to the public key.
The certificate is delivered to the applicant, who must protect the corresponding private key from disclosure.
The certificate is renewed or revoked as circumstances require.
PKI is used for applications such as authenticating web servers and users, validating digital signatures, and protecting email.
Trust chains and trust anchors
A CA certificate can itself be issued by another CA, creating a , often called a certificate chain. A typical chain is:
Each certificate is signed by its issuer. The verifier checks the signatures along the path and ultimately relies on a : a public key and associated information that the verifier already accepts. Trust anchors commonly come from an operating-system, browser, or organization-managed trust store. A is a starting point for validation, not something that is accepted simply because it is self-signed. Different applications and organizations may use different trust anchors and policies.
An intermediate CA allows an organization to issue certificates without using the root CA’s private key for routine signing. If an intermediate is compromised, it can be revoked or removed from trust without necessarily replacing the root. A chain may also have alternative paths, so path building may need to find a route that reaches an accepted .
Certificate
Finding a path and validating it are related but distinct tasks. finds certificates that may connect the target certificate to a . checks whether a proposed path satisfies the verifier’s requirements.
A verifier commonly checks that:
Each certificate’s signature verifies with the issuer’s public key, and the path reaches an accepted .
The certificates are within their validity periods and have not been revoked, where the application checks revocation status.
The certificate is appropriate for its intended use, based on fields such as key usage and extended key usage.
CA certificates are authorized to issue certificates, and constraints and certificate policies are respected.
The target identity matches the name or identity being authenticated. For HTTPS, the requested host name must match the certificate’s applicable subject alternative name.
Any critical certificate extension is understood. Under X.509 path-validation rules, an unsupported critical extension requires rejection.
Revocation information may be distributed through certificate revocation lists (CRLs) or queried using the . Revocation-checking behavior depends on the application and its policy; a certificate can be unexpired yet revoked.
For example, when a browser connects to shop.example, it checks that the certificate identifies that host, is valid for the connection’s purpose and time, and chains to a root it trusts. A valid chain alone is insufficient if the name does not match or the certificate is otherwise unacceptable.
What PKI can and cannot guarantee
PKI helps verify that a public key is associated with a claimed identity under a particular issuer and trust policy. It cannot guarantee that a CA’s checks were perfect, that the subject’s system is secure, or that a website is honest.
Trust therefore depends on the CA’s practices, the verifier’s trust-store choices, sound certificate validation, and protection of private keys. Publicly trusted TLS certificates are governed by industry requirements, while private organizational PKIs may follow their own policies. A valid certificate supports authentication, but does not by itself prove that a service is safe or trustworthy.