The primitives are complete, but Module 05 ended on a crack: cryptography proves what a key did, not whose key it is. If an attacker slips you their public key while you believe it is your bank's, the math works flawlessly — for the attacker. This module closes that gap and begins the second half of the track: putting the primitives to work in the real financial world. The answer is a structure called public-key infrastructure — certificates that bind a key to an identity, certificate authorities that vouch for them, and a chain of trust your browser follows every time it shows a padlock. You will inspect a real certificate, verify it the way a browser does, tamper with it and watch it break, and see how the whole thing can fail when a certificate authority is compromised.
Recall exactly where Module 05 left us. Public-key cryptography and digital signatures are powerful, but both depend on using someone's public key — you verify a signature with the signer's public key, you encrypt to your bank with the bank's public key. And nothing in the primitives themselves answers the obvious question: how do you know a given public key really belongs to the party you think? An attacker who substitutes their own key, labeled as your bank's, defeats everything while the math runs perfectly. Cryptography binds keys; it does not, by itself, bind keys to identities.
The idea that fills the gap is disarmingly simple, and it reuses the digital signature you just learned. If the problem is "I cannot trust that this public key belongs to my bank," the solution is to have someone I already trust sign a statement saying so. That signed statement — "the public key for yourbank.com is this specific key" — is called a certificate. It binds an identity (a domain name, a company) to a public key, and it is vouched for by the digital signature of a trusted third party. Because only that trusted party could have produced the signature (Module 05), and because any tampering with the statement would break the signature, a certificate is a tamper-proof, unforgeable voucher that a particular key belongs to a particular identity.
This is the whole concept of public-key infrastructure (PKI): a system for issuing, distributing, and verifying these signed bindings at the scale of the entire internet. It does not introduce any new cryptography — it is built entirely from the hash and the digital signature you already understand. What it adds is an organizational structure of trust: who is allowed to vouch, who vouches for them, and how your software checks the whole chain. That structure is what turns "I have a public key" into "I can trust this public key belongs to my bank," and it is what stands behind every padlock you have ever seen in a browser.
A certificate is a statement — "this public key belongs to this identity" — signed by a trusted third party. Because only the trusted party could produce the signature, and tampering would break it, the certificate is an unforgeable voucher binding a key to an identity. Public-key infrastructure is the system that issues and verifies these bindings at internet scale, built entirely from the hash and digital signature.
A certificate is just a small document with a few essential fields. Stripped to its essentials, it contains: the identity it vouches for (the domain name, like yourbank.com, and often the organization); the public key that belongs to that identity; some housekeeping (a validity period — certificates expire — and a serial number); the issuer (who is vouching); and, crucially, the issuer's digital signature over all of the above. That signature is what makes it trustworthy: it binds every field together so that changing any of them — swapping the key, altering the domain — invalidates the whole thing.
The party that issues and signs certificates is called a certificate authority (CA). A CA's entire job is to verify, before signing, that the entity requesting a certificate really controls the identity it claims — that whoever asks for a certificate for yourbank.com genuinely operates yourbank.com — and then to sign a certificate binding that domain to the key the bank provided. The CA is the "trusted third party" of the previous section, made concrete. When your browser later receives the bank's certificate, it checks the CA's signature: if it verifies, the browser knows the certificate's contents are exactly what the CA vouched for and were not altered.
This raises the natural next question, and it is the heart of how trust scales: why should your browser trust the CA? The answer is that your browser, and your operating system, ship with a built-in list of a relatively small number of trusted root certificate authorities — a "root store" — whose public keys are baked in and trusted by default. When a certificate is signed by one of these roots (or, as we will see, by an authority the root vouches for), your software accepts it. Trust is anchored in that pre-installed set of roots, and everything else chains back to them. That chaining is the next section.
A certificate authority (CA) verifies that an entity controls the identity it claims, then signs a certificate binding that identity to its public key. Your browser and operating system ship with a built-in "root store" of a small number of trusted root CAs whose keys are trusted by default. A certificate signed by a trusted root (directly or through a chain) is accepted; trust is anchored in that pre-installed set.
In practice, root CAs do not sign every website's certificate directly — their keys are too precious to use constantly, so they are kept offline and protected. Instead, a root signs certificates for intermediate CAs, and those intermediates sign the certificates for actual websites (called leaf or end-entity certificates). This produces a chain of trust: each certificate is signed by the one above it, all the way up to a root your browser already trusts.
When your browser connects to your bank, the bank sends its leaf certificate along with the intermediate(s). The browser then verifies each link: it checks the leaf was validly signed by the intermediate, and the intermediate was validly signed by a root — and if that root is in its trusted store, the chain is complete and trust flows from the root all the way down to the bank's key. Every link is a digital-signature check of exactly the kind you did in Module 05. If any signature in the chain fails to verify, or the chain does not end at a trusted root, the browser refuses the connection and warns you.
This structure is what lets trust scale to billions of websites without your browser needing to know any of them in advance. Your software only has to trust a small set of roots; those roots delegate to intermediates; intermediates vouch for individual sites. A handful of pre-installed root keys ultimately underwrites the authenticity of the entire encrypted web — which is elegant, and, as we will see in Section 6, also the system's greatest vulnerability.
A root CA (trusted by your browser) signs intermediate CAs, which sign individual website certificates — a chain where each link is a digital signature verifying the one below. Your browser follows the chain from the website's certificate up to a trusted root; if every signature verifies and it ends at a root in its store, trust is established. A small set of pre-installed roots underwrites the whole encrypted web.
Here is a real certificate-check, the kind your browser runs silently on every secure connection. The certificate below binds a domain to a public key and carries a certificate authority's signature over those contents (a genuine RSA signature, using the CA key from earlier modules). Your "browser" does two checks: first, is the issuer a CA in its trusted root store? Second, does the CA's signature actually verify over the certificate's contents? Both must pass. Try tampering — change the domain or the key an attacker would love to substitute — and watch the signature check fail; or switch the issuer to one your browser does not trust and watch it reject even a self-consistent certificate.
The certificate was signed by "Trusted Root CA" over the original domain and key. Edit any field, or change the issuer, and watch the two checks respond.
Notice the two distinct failure modes, because real attacks exploit both. If you edited the domain or key, the signature no longer matched the contents — that catches an attacker who takes a genuine certificate and tries to alter it, or who presents a key the CA never signed. If you switched to the untrusted issuer, the browser rejected it even though such an attacker could perfectly well sign their own certificate — because self-signing proves nothing when no trusted root vouches for the signer. Both checks are necessary: the signature proves the contents are intact and came from the issuer, and the trust-store check proves the issuer is one your system has decided to rely on. Together they finally close the man-in-the-middle gap from Module 05 — an attacker can no longer pass off their key as your bank's, because they cannot get a trusted CA to sign a certificate binding your bank's domain to the attacker's key.
Now we can assemble the whole picture, because the secure connection to your bank uses every primitive in this track together. The process that sets it up is called the TLS handshake (TLS, Transport Layer Security, is the protocol behind the S in HTTPS and the browser padlock). Watch how the four tools interlock in the first moments of a connection.
Trace the four primitives in those opening milliseconds. The bank presents its certificate; the browser verifies the certificate chain using digital signatures (Module 05), each of which is a signature over a hash of the certificate contents (Module 02) — that confirms it is really talking to the bank, closing the identity gap. Having trusted the bank's public key, the browser uses public-key cryptography (Module 04) to safely agree on a fresh shared secret with this party it has never met — solving key distribution. Then both sides switch to fast symmetric encryption (Module 03) using that shared key to protect the entire rest of the session — the bulk work, done quickly. Certificate, signature, public-key handshake, symmetric bulk encryption: the padlock you see is all four primitives firing in sequence, in well under a second, every single time.
This is the payoff of the whole first half of the track. Each primitive alone was insufficient — the hash could not keep secrets, symmetric encryption could not reach strangers, public-key was too slow for bulk, and signatures could not bind to identity without PKI. Woven together through TLS and PKI, they deliver exactly what digital finance requires: any browser, anywhere, can establish a fast, confidential, authenticated, tamper-proof channel to a bank it has never contacted, over a completely untrusted network, instantly. That capability is the foundation on which all of online banking and e-commerce is built.
In the evenhanded spirit of the course, we must look squarely at the weakness, and PKI has a serious one. The entire structure rests on trusting the certificate authorities — and that trust is a single point of failure. If a CA is compromised, tricked, or coerced into issuing a certificate it should not, the whole chain of trust can be turned against you.
Here is the attack. Suppose an attacker manages to get a CA — any CA your browser trusts — to issue them a certificate for yourbank.com, binding that domain to the attacker's key. Now the attacker can impersonate your bank perfectly: your browser checks their certificate, finds a valid signature from a trusted CA, sees the right domain, and shows the reassuring padlock. The man-in-the-middle gap we thought we closed is reopened — not by breaking any cryptography, but by subverting the human and institutional process of who gets vouched for. Every signature verifies; the certificate is "valid"; and it is catastrophic.
This is not hypothetical. There have been real, serious incidents in which trusted certificate authorities were breached or made mistakes and issued fraudulent certificates for major domains — in at least one notorious case, a compromised CA's mis-issued certificates were used to intercept the encrypted traffic of hundreds of thousands of people, and the CA was removed from browsers' root stores and collapsed as a result. Other incidents have involved CAs mistakenly issuing certificates for domains to the wrong parties. The lesson is sobering and honest: PKI moved the problem from "trust the math" (which is very strong) to "trust the institutions that vouch" (which is only as strong as their security and honesty). The cryptography is rarely the weak link; the human system around it is.
Because the stakes are so high, a layered set of defenses has grown up around PKI to limit the damage when a CA fails. None makes the system perfect, but together they make abuse far harder and far easier to detect.
The shape of the solution is worth noting: since the trust problem is institutional, the defenses are largely about transparency and accountability — making every CA action public and auditable, limiting its blast radius, and enabling quick detection and response. Certificate Transparency in particular has shifted the landscape, turning the secret mis-issuance of a certificate into something that is, in practice, very hard to hide. The cryptography was never the problem; these defenses harden the human system wrapped around it. It is an honest picture: PKI is indispensable and works astonishingly well at scale, and it carries a structural risk that the industry manages, rather than eliminates, through vigilance.
Defenses around PKI target its institutional weak point through transparency and accountability: revocation (cancel bad certificates), Certificate Transparency (public, append-only logs of every issued certificate so mis-issuance is caught fast), short certificate lifetimes (limit the damage window), and pinning (high-value apps accept only specific expected keys). They do not make PKI perfect, but they make abuse far harder to hide and faster to stop.
With PKI, the four primitives have been assembled into a working system that secures the open web: certificates bind keys to identities, a chain of trust scales that binding to billions of sites, and the TLS handshake weaves all four tools into the padlock that protects every online banking session and card-not-present purchase. The identity gap from Module 05 is closed — imperfectly, dependent on the honesty of certificate authorities, but well enough to underwrite the entire encrypted economy.
This was the first of the track's two "securing the real world" applications, and it covered the cryptography of the online world — connections, websites, servers. But an enormous share of finance happens through a different piece of hardware entirely: the payment card in your pocket, tapped or inserted at physical terminals billions of times a day. That world has its own cryptography — the chip on the card, the dynamic codes that defeat cloning, the tokenization that means your phone never reveals your real card number, and the hardware vaults that guard the keys. It uses the same primitives you now know, applied to a very different problem: proving a physical card is genuine and authorizing a payment at the point of sale.
The next module turns to exactly that. Having secured the connection between strangers across the internet, we descend into the chip-and-PIN, tap-to-pay machinery that secures the trillions flowing through card networks — the mostly invisible cryptography of everyday money. From there, the track moves to its largest application: the full Bitcoin and blockchain stack, where these same primitives are arranged into something genuinely new.
Six questions on PKI — what a certificate is, the role of certificate authorities, the chain of trust, the TLS handshake, and how the system fails and is defended. The questions test the concepts you just saw in action.