At the end of module 4 we left an uncomfortable sentence hanging in the air: all the mathematics is flawless, but it rests on an unverified assumption — that the public key you have belongs to who you think it does. MalloryClinic doesn't need to break RSA or Curve25519: all she needs is to slip you her public key while pretending to be Clínica Sol. In this lesson we finally build the missing piece: the X.509 digital certificate, a document that binds a public key to an identity with the signature of a trusted third party. You'll learn to read real certificates with openssl and with Python, understand the chain of trust that runs from your browser to a root authority, generate a CSR for portal.medinube.example, and set up a lab mini-PKI. By the end, MalloryClinic's attack from lesson 04-04 will stop working — and you'll know exactly why.

1. The crack in trust: what problem a certificate solves
2. Anatomy of an X.509 certificate
3. Inspecting a real certificate with openssl and with Python
4. The chain of trust: root, intermediate, and leaf
5. Certificate authorities: why the model works (and when it has failed)
6. The CSR: requesting a certificate for portal.medinube.example
7. Validation types: DV, OV, and EV
8. Lab mini-PKI for MediNube
9. How this defeats MalloryClinic

Let's recap the problem precisely. In 04-04, Clínica Sol wanted to establish an encrypted channel with MediNube using X25519. MalloryClinic placed herself in the middle and intercepted the public key exchange:

• To the clinic, she handed over her own public key, saying "I'm MediNube."
• To MediNube, she handed over another key of hers, saying "I'm Clínica Sol."

No primitive from the course detects this, because a public key, by itself, is just a number. It doesn't say whose it is. The signatures from 04-03 don't help on their own either: verifying Dr. Ferrer's signature requires having her authentic public key... which is exactly the same problem, one level up.

The solution isn't a new primitive. It's a document:

Digital certificate = public key + identity + signature from a trusted third party.

In other words: someone both parties already trust (the Certificate Authority, CA) examines the evidence that a public key belongs to an identity ("this domain," "this company") and puts it in writing, signed with its own private key, using exactly the digital signatures you already mastered in lesson 04-03. Whoever receives the certificate can verify that signature and, if they trust the CA, trust the key↔identity binding.

Notice that we haven't invented any new cryptography (golden rule 1): an X.509 certificate is a signed data structure. The novelty is organizational: who signs, what gets checked before signing, and how trust gets distributed.

X.509 is the standard certificate format (version 3, defined in RFC 5280). Its essential fields:

And one derived value you'll use constantly:

• Fingerprint: the SHA-256 hash of the full certificate encoded in DER. It's not part of the certificate; it's computed. It's used to identify it unambiguously ("is this the certificate we deployed?"), just like you used hashes in module 3 to verify integrity.

Historically, a server's identity went in the subject's CN (Common Name): CN=portal.medinube.example. That design had two problems: the CN only allows one name, and its semantics are ambiguous (it's a generic name field, not specifically a domain). The SAN extension fixes it: an explicit list of names (DNS:..., IP:...), with as many entries as needed.

Since 2017-2018, modern browsers and libraries completely ignore the CN when validating the server name: if the domain isn't in the SAN, the certificate is invalid, even if the CN matches. Practical rule for MediNube:

• The SAN is mandatory and it's the only thing checked for the name.
• The CN is decorative; it's filled in out of habit, but don't rely on it or validate against it.

The best way to internalize the anatomy is to open a real certificate. Let's download one from a real site and examine it (you can use any public domain; here's an example):

Breakdown of the second command, which you'll use hundreds of times in your career:

• x509: openssl subcommand for working with certificates.
• -in /tmp/wikipedia.pem: input file, in PEM format (the Base64 between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- you already met in 04-01; the raw binary form is called DER).
• -noout: don't reprint the PEM block.
• -text: show all decoded fields.

In the output, look for: Issuer:, Validity, Subject:, X509v3 Subject Alternative Name: (there are the domains!), X509v3 Key Usage, X509v3 Extended Key Usage: TLS Web Server Authentication, and at the end Signature Algorithm. Some quick queries without reading the whole dump:

Now the same thing from Python with cryptography.x509, the programmatic side MediNube will use in its automated checks:

Points worth understanding in the code:

• load_pem_x509_certificate parses the PEM into an immutable Certificate object.
• Extensions (SAN, Key Usage...) are queried with get_extension_for_class; if one doesn't exist, it raises ExtensionNotFound — on a modern server certificate the SAN must exist.
• fingerprint(hashes.SHA256()) is literally sha256(DER): module 3 working for module 5.

And who signs the CA's certificate? In practice, certificates form a chain:

• Root CA: a self-signed certificate (issuer = subject). Its private key is so valuable it's kept offline, in HSMs, and used very rarely: only to sign intermediates. Your trust in it doesn't come from any signature, but from the fact that it's preinstalled in your operating system's or browser's trust store (on Debian/Ubuntu: /etc/ssl/certs/, managed by the ca-certificates package; Firefox and Java ship their own).
• Intermediate CA: signed by the root. It's the one that does the day-to-day work of issuing certificates. If its key is compromised, the intermediate gets revoked without touching the root — it's an organizational firewall, another application of the crypto-agility and compartmentalization principle.
• Leaf certificate (end-entity): the server's own, with CA:FALSE. It cannot sign other certificates.

When a client (Ana Pérez's browser, or Clínica Sol's requests) receives the certificate for portal.medinube.example, it performs, among others, these checks:

1. Build the chain: the server sends the leaf and the intermediates; the client links each certificate to its issuer (one certificate's issuer must match the next one's subject) until it reaches a root that's already in its trust store.
2. Verify each signature: the issuer's public key verifies the child certificate's signature — exactly verify_signature() from 04-03, applied link by link.
3. Time validity: now ∈ [Not Before, Not After] at every link.
4. Constraints: the intermediates have CA:TRUE; the leaf has the right Key Usage (serverAuth).
5. The name: the requested domain appears in the leaf's SAN.
6. Revocation: has any of them been revoked? (The mechanisms — CRL, OCSP — we'll cover in 05-03; for now just remember that certificates also expire and get revoked.)

If everything passes, and only then, the client accepts that the leaf's public key belongs to portal.medinube.example. Trust flows from the root downward through verifiable signatures: that's a PKI (Public Key Infrastructure).

One practical nuance: in the Web PKI, leaves today use ECDSA P-256/P-384 or RSA keys. Ed25519 — MediNube's choice for prescriptions in 04-03 — is excellent, but browsers still don't accept it in public TLS certificates. Every context has its own ecosystem: internal prescriptions with Ed25519, web certificates with ECDSA/RSA. Crypto-agility, rule 8.

A CA is an organization whose business is verifying identities and signing certificates, subject to audits (the CA/Browser Forum's Baseline Requirements) under threat of expulsion from the trust stores. The model works because:

• It scales: you don't need to exchange keys in person with every website on the planet; it's enough to trust ~100-150 preinstalled roots.
• Trust is revocable: if a CA misbehaves, browsers kick it out and all its certificates instantly stop being valid.
• Incentives are aligned: the CA's livelihood depends on its reputation.

But it's a model with a structural flaw: any CA in your trust store can issue a certificate for any domain. Security is set by the worst CA on the list, not the best.

Historical case: DigiNotar (2011). This Dutch CA was compromised, and attackers issued over 500 fraudulent certificates, including one for *.google.com, used to intercept the email of thousands of users in Iran — a MalloryClinic at nation-state scale, with technically valid certificates. When discovered, browsers expelled DigiNotar from their trust stores, and the company went bankrupt within weeks. Double moral: the punishment system works, but the damage was already done.

The response: Certificate Transparency (CT). Since 2018, browsers require every public certificate to be logged in public, append-only logs (auditable, impossible to quietly rewrite). Anyone can monitor them: if tomorrow some CA issued a certificate for portal.medinube.example that MediNube never requested, the team would see it in the CT logs and alarms would go off. Keep the concept: CT doesn't prevent bad issuance, it makes it detectable. (You can explore the logs in public search engines like crt.sh.)

How does MediNube request a certificate from a CA? With a CSR (Certificate Signing Request): a file containing the public key, the requested identity (SAN included), and a self-signature proving that the requester possesses the corresponding private key. Crucial point: the private key never travels to the CA; it's generated and stays on MediNube's servers.

With openssl, in two commands (or one with -newkey):

The same thing from Python, useful for automating clinic onboarding in the future:

The CA receives the CSR, validates that you control the identity you're requesting (we'll see how next), and, if everything checks out, hands you back the signed certificate.

What exactly does the CA verify before signing? It depends on the certificate type:

Key detail: all three encrypt exactly the same way. The cryptography of a free DV and an expensive EV is identical; what changes is how much human identity is verified behind it. For MediNube's portal, an automated DV is the modern choice (and in 05-03 you'll see how to automate its issuance and renewal with ACME).

Let's build our own CA and sign a certificate, to get hands-on with everything above.

Lab use only. This CA is for MediNube's internal development environment and for learning. Never use a homemade CA for public services, and never casually install third-party roots into your trust store: whoever controls a root in your trust store can impersonate any website to you. In public production, always use a real CA (05-03). And remember: MediNube handles fictional health data in this course; a real deployment would additionally require security and GDPR compliance review.

That final openssl verify runs, in miniature, exactly what your browser does: it builds the chain portal.crt → ca.crt and verifies signature, dates, and constraints. Check the result too with what you've learned: openssl x509 -in portal.crt -noout -subject -issuer -ext subjectAltName — you'll see the issuer is no longer the subject itself, but your lab CA. (We've skipped the intermediate to keep things simple; the principle with three links is identical.)

Let's go back to the 04-04 attack diagram, now with certificates in play:

MalloryClinic has exactly three options, all bad:

1. Present her own key with a self-signed or homemade-CA certificate → the chain doesn't end at any root in the clinic's trust store. Rejected.
2. Present a valid certificate for a different domain (one she legitimately obtained) → the chain's signature validates, but portal.medinube.example isn't in its SAN. Rejected.
3. Get a real CA to issue her a certificate for portal.medinube.example → she'd have to pass domain-control validation without controlling the domain, and even if a CA failed (DigiNotar), Certificate Transparency would leave the fraudulent certificate in plain view of MediNube's monitors.

The CA's private key signs the identity↔key binding before Mallory can ever get involved, and that signature travels with the certificate. The crack we've been carrying since 04-01 is, at last, technically closed. Note the price: we've added a trusted third party and a whole operational apparatus around it — certificates that expire, get renewed, and get revoked (05-03).

• Validating against the CN instead of the SAN. Legacy code that compares the CN "by hand" accepts certificates no browser would ever accept. Leave name validation to the library (you'll see it in 05-02); if you ever have to do it yourself, SAN and only SAN.
• Confusing the certificate with the private key. The .crt is public, freely given away; the .key is the secret. Sending someone "the certificate" never includes the key. If a CA ever asks for your private key, run.
• Sending the private key along with the CSR. The CSR already contains the public key and proof of possession; the private key never leaves the server. Never.
• Disabling verification "because it's failing." A certificate validation error is the system working. The temptation to silence it (the verify=False you'll find in legacy MediNube code in 05-02) is equivalent to going back to the 04-04 world where Mallory ran free.
• Installing roots into the trust store carelessly. Every root you add can impersonate any site to you. This lesson's lab root: controlled development environments only.
• Ignoring Basic Constraints and Key Usage when issuing. A leaf carelessly issued with CA:TRUE can sign certificates for any domain. When setting up your mini-PKI, always mark the leaf as CA:FALSE (the default if you don't add the CA extension) and restrict its usages.

Exercise 1 — Autopsy of a real certificate. With openssl s_client + openssl x509, download the certificate of a public domain you use daily and answer: (a) who is the issuer and who is the subject? (b) how many names are in the SAN? (c) how many total days of validity does it have? (d) what's its SHA-256 fingerprint?

Exercise 2 — Auditor in Python. Write a function audit_certificate(pem_path: str) -> list[str] that loads a certificate with cryptography.x509 and returns a list of warnings: "EXPIRED" if it's already expired, "NO_SAN" if it lacks the SAN extension, and "EXCESSIVE_LIFETIME" if Not After − Not Before exceeds 398 days (the maximum browsers accept today). Test it with the certificate from exercise 1 and with your lab's portal.crt.

Exercise 3 — Mallory vs. your mini-PKI. In your lab, generate a second CA (mallory-ca.key / mallory-ca.crt, CN MalloryClinic CA) and use it to issue a certificate for portal.medinube.example (Mallory can write whatever she wants in her own certificates!). Verify with openssl verify -CAfile ca.crt mallory-portal.crt that it does not validate against MediNube's legitimate root, and reason through why this exactly models the MITM's defeat.

Solution 1. Example session (the actual values will depend on the domain and the date):

It's common to find issuers like Let's Encrypt (C=US, O=Let's Encrypt, CN=...) — an intermediate CA, not the root: remember the leaf is almost never signed directly by the root.

Solution 2.

Details that matter: we use the _utc properties and compare against datetime.now(timezone.utc) (mixing timezone-aware and naive datetimes raises TypeError); the SAN is detected by catching ExtensionNotFound, not by checking for None. Your lab's portal.crt should return []; many old intranet certificates return NO_SAN and EXCESSIVE_LIFETIME at the same time.

Solution 3.

Reasoning: the content of Mallory's certificate is identical to the legitimate one (same SAN, same structure); what she can't forge is the signature of a root the victim already trusts, because she doesn't have its private key. Trust isn't in what the certificate says, but in who signs it — exactly the unforgeability property of signatures from 04-03, raised to infrastructure.

The crack that had been chasing MediNube since 04-01 finally has a technical fix: an X.509 certificate binds a public key and an identity with the verifiable signature of a CA, and the chain of trust (offline root in the trust store → intermediate → leaf) lets you validate that signature without having exchanged anything in person. You've learned to read the anatomy of a certificate (with the SAN as the field that truly rules), to inspect it with openssl x509 -text and with cryptography.x509, to generate a CSR without the private key ever leaving home, to tell DV/OV/EV apart, and you've set up a lab mini-PKI with which you verified, in your own terminal, that MalloryClinic's certificates don't validate. You also saw that the model has cracks of its own (DigiNotar) and watchdogs (Certificate Transparency).

But a certificate sitting still in a file protects nothing. What's missing is the protocol that puts it to work on every one of Ana Pérez's connections to the portal: the one that presents the certificate, agrees on ephemeral keys with ECDH, derives keys with HKDF, and encrypts with AEAD. Every single piece will sound familiar, because you've spent four modules building them. In the next lesson, 05-02: TLS in Practice, you'll see them click into place in the world's most-used security protocol.