Cryptography › Module 3 › Lesson 3
Certificate Authorities
How CAs vouch for sites—and what happens when trust is broken
Opening
Someone has to vouch — CAs sign names to keys. When that voucher lies or leaks, the web’s passport office is on fire.
Your phone and laptop ship with a list of trusted root Certificate Authorities. A CA’s job is to bind a hostname to a public key after some validation, then sign that statement so browsers will accept the leaf you met in the last lesson. That is web PKI: you do not phone every site to ask “is this really example.com?” You trust a small set of roots, and chains of intermediates, to have done a check. That power is why a mis-issued certificate for a bank, or a compromised CA, is headline news — and why installing a random root CA from a chat is how you volunteer to trust an attacker’s signatures forever. This lesson is voucher mechanics, failure modes, and Certificate Transparency as a public log you should know exists — not a CT-hunting exploit kit. You will write CA rules into $HOME/cyberlium-lab. You will not add roots. You will not run a rogue CA. You will not intercept traffic. Next is the cert lab: openssl and curl against example.com or a domain YOU own, then the module quiz.
1. What a CA actually does: validate control, sign a leaf, revoke when the story breaks
Domain Validation (DV) is the common web path: prove you control the domain (HTTP challenge, DNS TXT, or similar), then receive a certificate for those SANs. Organization Validation (OV) and Extended Validation (EV) add identity checks on a legal entity. Browser UI no longer treats EV as a giant green company name the way 2012 marketing promised — the padlock looks similar — but the CA’s validation policy still differs. Let’s Encrypt and other automated CAs are real CAs: free is not fake. Fake is an untrusted issuer, a name mismatch, or a root you installed because a PDF said “trust this.” Issuance is a signature: the CA (usually an intermediate) signs the leaf. Your client walks the chain to a root in the trust store. Revocation exists because keys leak and names get sold: CRL, OCSP, and newer short-lived certificates that expire before a long CRL drama. Clients are imperfect at checking revocation; that is an industry sore point, not a reason for you to disable all checks. As a site operator you automate renewal before Not After. As a user you do not click through unknown-CA warnings on email or banks to “just get in.”
Roots are loaded by OS and browser vendors. Enterprises sometimes add a corporate root so a TLS-inspecting proxy can re-sign traffic on company-owned laptops under a written policy. That is a different universe from you downloading SchoolPortalRoot.crt off a forum onto a personal phone. This course’s rule: do not install random root CAs. Do not run mkcert-style local CA experiments against anyone else’s device. A lab on YOUR machine with a tool you understand is still not “install this root on the family tablet so homework loads.” Trust stores are the crown jewels of TLS. Treat extra roots as a deliberate, rare, documented act — not a troubleshooting click.
2. When trust breaks: mis-issuance, distrust events, and CT logs as a public smoke alarm
Mis-issuance means a CA signed a certificate that should not exist: wrong domain, insufficient validation, a leaf that looks like a CA, or a cert for a name the applicant did not control. History has CA distrust events: browsers and OS vendors remove or constrain a root so that CA’s new signatures stop counting. That is how the ecosystem answers “the passport office stamped forgeries.” You will not be given a list of attack recipes. You will remember the defender move: if a warning says the issuer is untrusted, that may be the system working. Certificate Transparency (CT) is a system of append-only public logs. Public CAs are expected to submit certificates so the world can see what was issued for a domain. Domain owners (and researchers) watch logs for unexpected names: a certificate for yourbank.com you did not request is a fire alarm. Browsers may require CT evidence (SCTs) on publicly trusted certs. Conceptual CT in this course: a glass book of issuance, not a command to scrape every log as a weapon, not a MITM technique. If you operate a domain, monitoring CT is hygiene. If you do not, you still need the sentence “unexpected issuance can be spotted in public logs.”
Trust-break map — three rooms. None of them are “install this root to proceed.”
Mis-issuance
A CA signed the wrong name or skipped validation. The signed object can still look like a normal cert until distrust or CT notice.
Distrust
Vendors remove or constrain a root. Sites that only chained to that CA start failing — noisy, but a safety valve.
CT logs
Public, conceptual: unexpected certs for a domain can be noticed. Not a license to attack CAs or intercept holders.
3. Wrong vs right: random roots and rogue CAs vs vouching, CT literacy, and a locked trust-store rule
Worked failure — silencing ERR_CERT_AUTHORITY_INVALID with a forum .crt. Right is understanding the voucher and refusing extra roots.
Wrong
Install a root CA from email, Discord, or a “fix school Wi-Fi” PDF on a personal device. Run a rogue CA and push it to a classmate. Disable all CA checks globally (verify=False in production). Treat Let’s Encrypt as fake because it is free. Ignore CT as “only researchers.” Intercept café traffic with your own CA. That is how you become the mis-issuance.
Right
Write: CAs bind names to keys; DV proves domain control; roots live in OS/browser stores; mis-issuance and distrust are real; CT logs are a public way to notice unexpected issuance. Never install random roots. Notes in $HOME/cyberlium-lab, chmod 600. Next: Lab — Analyze SSL Certificate on example.com or a domain you own.
4. Practical: ca-trust-notes.txt — voucher rules, no extra roots, no live secrets
You do not need to operate a CA. You need a file that will still make sense at 02:00 when a warning appears. Record what a CA vouches, why extra roots are dangerous, one sentence on CT, and the ethics line. Optional: openssl s_client to example.com and copy the issuer field you already know how to print — that issuer is the voucher, not a root you add. Do not run trust-store modification commands “to see what happens.” Do not paste live private keys. Lock the notes.
ca-trust-notes.txt — PKI voucher rules, YOUR lab folder, never addstore
# DEFENSIVE CA literacy. YOUR notes.
# NEVER certutil -addstore / trust a random .crt / mkcert on someone else's phone.
mkdir -p "$HOME/cyberlium-lab"
NOTES="$HOME/cyberlium-lab/ca-trust-notes.txt"
{
echo "=== CERTIFICATE AUTHORITIES ==="
echo "job: vouch that a public key belongs to a name (SAN) after validation"
echo "DV: prove domain control. OV/EV: extra org checks. UI padlock still != honesty."
echo "Let's Encrypt and other automated CAs are real when the chain validates. Free != fake."
echo "chain: leaf -> intermediate(s) -> root in OS/browser trust store"
echo "revoke/renew: operators rotate before Not After; users do not click through unknown CA on banks"
echo ""
echo "mis-issuance: CA signed something that should not exist"
echo "distrust: vendors constrain or remove a root"
echo "CT logs (conceptual): public record of issuance; unexpected certs for a domain can be noticed"
echo ""
echo "optional issuer from public cert (example.com OR a domain I own):"
echo "issuer:"
echo ""
echo "RULE: do not install random root CAs"
echo "ethics: no rogue CA, no MITM, no intercepting others, no live private keys"
} > "$NOTES"
# Optional public issuer read — allowed. Not a trust-store change.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer
chmod 600 "$NOTES"
# Windows without chmod: WSL/Git Bash, or restrict the file in your profile.
# NEVER: sudo cp anything.crt /usr/local/share/ca-certificates && update-ca-certificates (random roots)
# NEVER: install a classmate's "lab CA" on a shared PC
# NEVER: mitmproxy --set confdir with a CA you push to other peopleMission: ca-trust-notes.txt — CAs vouch, CT exists, no random roots (mode 600)
1) In your own words: a CA binds a name to a public key; clients trust roots in the OS/browser store; DV proves domain control, not that the shop is honest. 2) Write mis-issuance, distrust, and Certificate Transparency as a conceptual public log. Write the rule: do not install random root CAs. 3) Save as $HOME/cyberlium-lab/ca-trust-notes.txt and chmod 600. Optional issuer read on example.com or a domain YOU own. Never add a root. Never intercept others.
Stuck? Ask Cyberlium AI Mentor
If “the red CA error is just Chrome being annoying” still feels true, ask for a hint — not an addstore command. Try: "Hint only: what does a CA vouch, why is a random root a MITM gift, what is mis-issuance, and what are CT logs for conceptually?" You still fill ca-trust-notes.txt. No fake CAs. No intercepting others. No live keys.
You now treat CAs as the web’s passport office: useful when honest, catastrophic when fooled or when you add a stranger’s stamp to your wallet. CT is a glass log, not a weapon. Next — Lab — Analyze SSL Certificate — you will use openssl s_client and curl on example.com or a domain YOU own, write subject, issuer, and dates to cert-lab.txt, and chmod 600. Still no MITM. Then Quiz — TLS/HTTPS.
Knowledge Check
APPLY: A portal shows ERR_CERT_AUTHORITY_INVALID. A PDF says “install this root so login works.” A classmate says Let’s Encrypt is fake because it is free. What is a CA’s job, and what do you refuse?
Multiple choice
Knowledge Check
APPLY: True or False: Operating systems and browsers ship with trusted root stores, and Certificate Transparency is a conceptual public way to notice unexpected issuance — which authorizes you to run a rogue CA on a roommate’s laptop.
True or False
Knowledge Check
APPLY: News says a CA mis-issued certs and browsers will distrust the root. Your move as a learner, and what goes in the notes?
Multiple choice