Public Key Infrastructure (PKI)

Strip the PDF mystique. An X.509 certificate is structured data: a subject (the name being claimed), a public key, a validity window (notBefore / notAfter), an issuer, and a signature over that data. The signature is not encryption of your traffic. It is the issuer’s private key saying “I attest this binding.” Anyone with the issuer’s public key can verify that signature — which is lesson 4’s mechanism, used here as glue. If the signature verifies and the name matches what you intended to reach, you will use the subject’s public key to continue (in TLS, to authenticate the handshake).

What a certificate is not: a secret. Certificates are copied, logged, stapled into handshakes, pasted into tickets. The secret is the matching private key, held by the subject (the site, the VPN appliance, the code-signing laptop). Stealing the .crt without the private key does not let you impersonate the name. Stealing the private key does — until revocation and expiry catch up, imperfectly. This module does not teach you to steal keys. It teaches you to stop treating a green lock as “the company is moral” and start treating it as “this public key is bound to this name by a chain I trust.”

Browsers do not ship every website’s public key. They ship a comparatively small set of root CA certificates — trust anchors. A typical HTTPS cert is signed by an intermediate CA, whose cert is signed by a root. Verification walks that chain: check signatures, check validity windows, check that intermediates are allowed to issue, check that the name in the leaf matches the host you typed. If any step fails, you get a warning. The warning is the product working. Clicking through because a helpdesk script said so is how people install malware with a smile.

Trust is not transitive friendship. Trusting a root means you accept certificates that root (and its authorized intermediates) issue, within policy. A compromised or mis-issuing CA is a sector-wide incident — that is why Module 3 spends time on CAs, and why real PKI includes revocation (CRL / OCSP), Certificate Transparency logs, and name constraints. You do not need those protocols memorized today. You need the picture: your trust starts at an anchor you did not generate this afternoon in cyberlium-lab. A chain that ends at a self-signed toy is a chain that ends at you talking to yourself.

openssl genrsa succeeded. openssl req -x509 can even wrap that key in a self-signed certificate that says CN=paypal.com if you type that string. The file will look like a certificate. OpenSSL will not call the police. Your browser, facing the real PayPal, will not replace the WebPKI chain with your toy. If you force a client to trust your toy as a root, you have built a private PKI — powerful on a lab VM you own, dangerous if you sneak that root onto other people’s machines. This course does not sneak roots. The lab self-signed exists so you can read the fields and then delete it, saying out loud: subject string ≠ identity unless a trust anchor you already had signed the binding.

Phishing uses the gap: a cert can be valid for login-paypal.example while the padlock is honest about a dishonest name. Read SAN/CN and the issuer. You will not intercept other people’s HTTPS or mint lookalike certs. Module 3’s CA lessons are issuance on hosts you own — not a forgery kit for the public web.

A CA’s job is identity vetting plus signing. Automated issuance (ACME / Let’s Encrypt-class) proved domain control with HTTP or DNS challenges — still not “the company is good,” still “they proved they control this name for now.” Extended Validation marketing is less of a user-interface religion than it was; name matching and chain validity remain. Lab CAs in Module 3 are for hosts you own. They are not a license to mint certificates for domains you do not control. Forgery of public-web certificates is an attack. This lesson stops at literacy so signatures (next) make the issuer’s pen feel mechanical rather than magical.

The required artifact is pki-lab-notes.txt you authored. The optional openssl req -x509 block exists to make “self-signed is not a trust anchor” tactile. Use a fictional CN. One day of validity. Delete the key. Do not add this cert to a browser trust store. Do not aim it at a real domain. Do not intercept anyone’s traffic.

mkdir -p "$HOME/cyberlium-lab"
cd "$HOME/cyberlium-lab"

{
  echo "=== PKI LAB NOTES (no private keys) ==="
  echo "cert_binds: subject name + public key + validity + issuer signature"
  echo "secret: the subject's private key — the .crt is not the secret"
  echo "chain: leaf -> intermediate(s) -> trust anchor (root already on the OS/browser)"
  echo "identity: openssl genrsa is NOT identity; anyone can generate a pair"
  echo "name_match: valid cert for evil-bank.example != your bank"
  echo "self_signed: subject signs itself — fine on a lab VM YOU own, not WebPKI"
  echo "module_3_preview: CAs, issuance, lab certs on hosts you control"
  echo "ethics: no rogue roots on other people, no public-web forgery, no site attacks"
} > pki-lab-notes.txt
chmod 600 pki-lab-notes.txt 2>/dev/null || true

openssl req -x509 -newkey rsa:2048 -keyout toy-pki-key.pem -out toy-pki-cert.pem \
  -days 1 -nodes -subj "/CN=not-really-a-bank.example"

openssl x509 -in toy-pki-cert.pem -noout -subject -issuer -dates -fingerprint

Subject == issuer on a self-signed toy. That is the lesson: it vouches for itself.

chmod 600 toy-pki-key.pem toy-pki-cert.pem 2>/dev/null || true
rm -f toy-pki-key.pem

You now separate keys from names: a certificate is a signed binding, a chain is a walk to an anchor, and a key you generated this hour is not PayPal. Module 3 will put CAs in the chair. Next — Digital Signatures — is the issuer’s pen in slow motion: hash the bytes, sign with a private key, verify with a public key. Authenticity and integrity, not confidentiality. Optional openssl dgst -sign on a file YOU own. No forging signatures as an attack.