PKI & Certificates

Verifying Digital Identity

Physical identity verification relies on a document issued by a defined authority and on procedures for checking its data and security features. A bank can inspect the document, compare the photograph with the person, and check whether it comes from an accepted source. Trust follows from issuance rules, safeguards, and the responsibility of the authority that issued the document.

During an Internet connection, a browser must check whether a public key belongs to the server named by the user. Page content alone does not prove identity, since an attacker can create a copy and attempt to intercept the connection. Digital certificates, signatures, and validation procedures bind a service name to a public key. This mechanism is provided by Public Key Infrastructure.

What is Public Key Infrastructure (PKI)?

Public Key Infrastructure (PKI) includes roles, policies, hardware, software, and procedures for creating, managing, distributing, using, storing, and revoking digital certificates. Its primary purpose is to bind a public key to a specific entity, such as a person, organization, or server, under an established trust policy.

PKI covers the certificate life cycle: applicant identification rules, issuance, key protection, certificate publication, trust-path validation, and revocation. A digital certificate is a document containing a public key and subject data. Correct validation requires policy compliance and a check of the certificate's current status. A deployment also defines how private keys are generated and stored, how certificates are renewed, and which roles may issue or revoke them. A relying party must know the CA policy and accepted trust anchors, while the certificate holder must protect the private key. Policies commonly specify algorithms, key sizes, validity periods, emergency procedures, and audit requirements. A certificate does not replace authorization checks: it confirms a defined binding between a key and an entity, while the application still decides which permissions to grant. The policy also defines renewal, recovery after key compromise, evidence retention, and the responsibilities of relying parties. These controls determine whether a certificate remains useful throughout its life cycle.

Core PKI Components

PKI contains roles and components that work together to issue certificates, verify identity, publish data, and maintain trust.

1. Certificate Authority (CA): Certificate Issuance.

   The Certificate Authority (CA) issues certificates under its policy and protects the private key used for signing. Before issuance, the CA applies defined methods to verify the applicant. The CA signature lets a relying party check that the certificate came from the stated issuer and that its signed data was not changed. Trust in a CA follows from configuring its key as a trust anchor or from building a path to such an anchor. A CA may issue end-entity certificates or intermediate CA certificates. Examples of public CAs include DigiCert, GlobalSign, and Let's Encrypt.

2. Registration Authority (RA): Request Processing.

   In large PKI deployments, a CA may delegate identity verification to a separate Registration Authority (RA). The RA accepts requests, performs initial checks under the CA's policy, and forwards the validated request to the CA. The RA does not have to sign the certificate; final issuance remains a CA operation. Separating the RA and CA limits the number of people who can access the signing key. Procedures should define request transfer, verification evidence, and handling of rejected or expiring certificates.

3. Digital Certificates: X.509 Documents.

   A digital certificate is an electronic document used by PKI. It most commonly has the X.509 structure and contains information binding an entity's identity to its public key. Defined fields and the issuer signature support document validation.

4. Certificate Revocation Mechanisms (CRL and OCSP).

   If a private key is exposed or trust conditions change, a CA may revoke the certificate before it expires. PKI publishes certificate status through the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP). Software checks this information according to its validation policy.

5. Certificate Repository: Data Publication.

   A repository is a directory or database where a CA publishes issued certificates, CRLs, and data needed for validation. A user or application can retrieve the certificate and status data according to the access policy. Publication points and status-service addresses may be carried in the certificate or supplied by client configuration.

Digital Certificate Structure (X.509)

An X.509 certificate has a defined structure. It contains fields identifying the issuer and subject, a validity period, a public key, and the issuer signature.

• Version: Indicates which version of the X.509 standard the certificate adheres to (usually version 3).
• Serial Number: A unique positive integer assigned by the CA that unambiguously identifies this specific certificate from all others issued by that CA.
• Signature Algorithm: The algorithm that the CA used to sign this certificate (e.g., SHA-256 with RSA).
• Issuer: The identity of the Certificate Authority that verified the information and issued this certificate. The issuer's certificate supplies the public key used to verify the signature.
• Validity Period: The start and end dates for which the certificate is considered valid (the "Valid From" and "Valid To" dates). The validator compares them with the current time according to its clock-checking policy.
• Subject: The identity of the person, organization, or device to whom the certificate belongs. In a TLS certificate, the service name is normally placed in the Subject Alternative Name extension, such as a DNS-ID. Common Name can be used only in a limited client-defined mode.
• Subject's Public Key Information: This field contains the actual public key of the subject, along with the algorithm with which the key is used (e.g., RSA or ECC). Extensions can specify key uses, CA constraints, CRL publication points, and an OCSP responder address. These extensions limit the contexts in which the certificate may be used.
• Issuer's Digital Signature: The CA signs the encoded certificate data with its private key and a specified algorithm. A relying party verifies the signature with the issuer's public key and then checks the remaining validation conditions. A signature does not encrypt the certificate.

The Chain of Trust and Validation

A chain of trust connects an end-entity certificate to an intermediate certificate and a trust anchor. An operating system or browser has its own store of trusted root CAs. A validator builds a path and checks signatures, CA constraints, names, and validity periods according to policy.

Here is the step-by-step verification process when you visit a secure website:

1. Presentation: Your browser connects to 'https://www.example.com', and the server presents its SSL/TLS certificate. Let's call this the "End-Entity Certificate."
2. First Check: The browser examines the "Issuer" field of the End-Entity Certificate. It says, for instance, "Example Intermediate CA". It also checks whether the service name matches an identifier in the certificate.
3. Walking the Chain: The browser checks its trusted root store. "Example Intermediate CA" is not on that list, so the server may also present its certificate. The browser analyzes it as the next element in the path. The server does not have to send the root certificate because the client stores the trust anchor locally.
4. Second Check: The browser looks at the "Issuer" field of the "Example Intermediate CA" certificate. This one says it was issued by "Example Root CA". The browser also verifies the signature on the End-Entity Certificate using the public key from the Intermediate CA's certificate and checks whether the intermediate may issue certificates.
5. The Trust Anchor: The browser checks its list of trusted Root CAs again. This time, it finds "Example Root CA" on the list. It treats that certificate as a trust anchor according to its configuration. It then uses the public key from the trusted Root CA certificate (which it already has) to verify the digital signature on the Intermediate CA's certificate.
6. Trust Established: If the intermediate certificate signature is valid, its CA constraints are satisfied, and its issuer is a trusted anchor, the browser can accept the path. It then checks the end-entity signature, service name, validity period, and revocation status. The interface may indicate a valid connection. Validation also includes key usage and path-length constraints.

The hierarchy from a root CA through one or more intermediate CAs to the end entity separates roles and limits the number of root keys stored as trust anchors. Acceptance depends on validation of the complete path. Path validation also checks whether each certificate is permitted for its role and intended use. A valid signature alone does not establish trust when the name, policy, time, or key-usage conditions fail.

Certificate Revocation

If the private key for 'www.example.com' is exposed, the CA may revoke the certificate before its expiry. Software checks the status through CRL or OCSP, depending on its validation policy.

Certificate Revocation List (CRL)

A CRL is a list published and digitally signed by a CA. It contains the serial numbers of certificates revoked before expiration. The browser retrieves the list from a CA publication point, then checks its signature, scope, dates, and the presence of the serial number.

Limitations:CRLs can be large and costly to download. They are published on a CA schedule, for example every 24 hours, so a delay can occur between key exposure and publication of the next list. A client should check the list's validity interval and number to detect stale data.

Online Certificate Status Protocol (OCSP)

OCSPreduces the need to download an entire CRL. The browser sends the CA responder a request containing the certificate identifier and receives a signed response. The response reports 'good', 'revoked', or 'unknown' and includes information about the response validity interval. The validator checks the response signature, responder identity, and freshness; client behavior when the responder is unavailable follows local policy.

OCSP Stapling: In the classic model, a browser may send status queries to the CA, affecting privacy and performance. With OCSP Stapling, the web server periodically obtains a signed response for its own certificate and attaches it to the TLS exchange. The browser can check the response from the server without a separate request to the CA responder.

SSL/TLS Certificate Validation Levels

Certificates can differ in the scope of subject verification. The validation type follows from the CA procedures applied before issuance. Three main levels are commonly described:

• Domain Validated (DV):This is the most basic level of validation. The CA only verifies that the applicant controls the domain name for which they are requesting the certificate. Validation can use an HTTP challenge, a DNS record, or TLS-ALPN; some CAs also allow a message sent to a controlled email address. The exact methods depend on the CA. The certificate can be used in a TLS connection that provides encryption, but it makes no claim about the legal identity of the website's operator. Let's Encrypt is a famous provider of free DV certificates. Domain control does not approve the service's content or security.
• Organization Validated (OV):This involves a more thorough vetting process. The CA requires the applicant to provide documentation proving the legal existence and physical location of their organization. The organization's name is included in the certificate, providing additional information to relying parties when a client displays it.
• Extended Validation (EV):The CA applies a more extensive procedure following industry guidelines. It verifies the organization's legal, operational, and physical existence and its right to use the domain. Historically, browsers displayed the organization's name in a green bar for EV certificates, though most modern browsers have removed this special treatment. EV describes the validation procedure and does not guarantee that the service itself is safe.

PKI and digital certificates support entity authentication, key protection, and certificate status checks. Security depends on correct path validation, name matching, current status data, and protection of private keys. Operators must maintain trust stores and retire compromised or obsolete keys.