I85PREP
⌘ K
EECC study materials
EECC study resources

EECC: Public Key Infrastructure and Digital Certificates

EECC · Work through your exam, one topic at a time.

All guide sections

Public Key Infrastructure and Digital Certificates

Public Key Infrastructure and Digital Certificates

This domain tests how a certificate binds an identity to a public key, and how a relying party decides whether to trust that binding.

Core components and rules

  • CA and RA. The certificate authority signs certificates; the registration authority verifies identity before issuance. The CPS documents the practice statement.
  • X.509 v3 fields. Version, serial number, signature algorithm, issuer, validity (notBefore/notAfter), subject, subject public key info, and extensions.
  • Key extensions. subjectAltName (the field browsers actually match hostnames against), keyUsage, extendedKeyUsage, basicConstraints (marks a CA and its path length), CRL Distribution Points, Authority Information Access.
  • Chain of trust. Leaf → intermediate → root. The root is a trust anchor in the OS or browser store. Validation checks each signature, validity dates, key usage, name constraints, and revocation.
  • Revocation. CRLs are periodically published lists; OCSP queries status in real time; OCSP stapling lets the server supply a signed response.
  • Validation levels. DV (domain control only), OV (organization vetted), EV (extended vetting, historically a green bar).

Worked example

A browser connects to shop.example.com. The server sends a leaf certificate plus an intermediate. The browser verifies the leaf's signature with the intermediate's public key, then the intermediate's signature with a root already in its store; checks the leaf's validity window and that SAN contains shop.example.com; then queries OCSP for revocation status. Any failure - expired, wrong SAN, revoked, unknown issuer - raises a warning.

Traps

  • Assuming the subject CN still governs hostname matching; SAN does.
  • Treating a self-signed certificate as automatically trusted.
  • Confusing a CRL's publish interval with real-time status.
  • Believing a certificate proves the site is honest; it proves key-to-name binding only.
  • Forgetting that an intermediate's basicConstraints must permit CA issuance.