SLIDE 1 / 10
CSZone.co.uk
Click anywhere to advance · Arrow keys also work
AQA 7517 · Paper 2 · 4.5.6d

Certificate Authority
& Chain of Trust

Digital certificates · PKI · HTTPS trust model · Section 4.5

WHAT YOU'LL LEARN
Digital certificates · CA hierarchy · Chain of trust · MITM attacks · PKI
AQA SPEC LINK
4.5.6 — Certificate authorities, digital certificates, chain of trust
The Problem

How Do You Trust a Public Key?

When you connect to bank.co.uk, the server sends you its public key. But how do you know it's actually from the real bank — and not from a hacker in the middle?
A Man-in-the-Middle (MITM) attack could intercept and substitute a fake public key
You'd encrypt to the hacker, not the bank — all your data exposed
Solution: Digital Certificates issued by trusted Certificate Authorities (CAs)
Digital Certificates

What's in a Digital Certificate?

Subject: bank.co.uk
Public Key: [bank's RSA public key]
Issuer: DigiCert (Certificate Authority)
Valid: 2025-01-01 to 2026-01-01
Signature: [CA's digital signature]
The CA's signature on the certificate proves the public key genuinely belongs to bank.co.uk. If the certificate is tampered with, the signature won't verify.
Certificate Authority

What is a Certificate Authority (CA)?

A trusted third party that verifies identities and issues digital certificates
Examples: DigiCert, Let's Encrypt, Comodo, GlobalSign, Sectigo
CA checks the organisation really owns the domain before issuing a certificate
CA signs the certificate with its own private key — browser verifies using CA's public key (pre-installed)
Your browser/OS ships with a list of ~100+ Root CA public keys it trusts by default
Chain of Trust

The Certificate Chain

🌳 Root CA (self-signed, pre-installed in OS/browser)
    ↓ signs
🌿 Intermediate CA (signed by Root CA)
    ↓ signs
🍃 End-entity certificate (e.g. bank.co.uk)
Browser traces the chain: leaf cert → intermediate CA → root CA. If the root CA is trusted, the whole chain is trusted. This is the "chain of trust".
HTTPS Verification

What Happens When You Visit HTTPS

Browser connects to server → server sends its certificate
Browser checks: Is the certificate signed by a trusted CA? (traces chain of trust)
Checks: Is the domain name in the cert the same as the site you're visiting?
Checks: Is the certificate still within its validity period? (not expired or revoked)
All checks pass → padlock shows ✓ TLS handshake proceeds
MITM Prevention

How Certificates Stop MITM Attacks

Hacker intercepts connection and presents their own public key (fake):
→ They'd need a certificate signed by a trusted CA for bank.co.uk
→ CAs won't issue one without proving ownership of the domain
→ Browser rejects certificate with "Not Secure" warning
A hacker could create a self-signed certificate, but your browser won't trust it — the chain of trust breaks at the top.
PKI

Public Key Infrastructure (PKI)

PKI is the complete system of CAs, certificates, and protocols that enables secure public-key cryptography on the internet
Includes: Root CAs, Intermediate CAs, certificate issuance policies, revocation mechanisms (CRL, OCSP)
Certificate Revocation — if a private key is compromised, the CA can revoke the certificate before expiry
The entire trust of HTTPS relies on CAs not being compromised — a rogue CA is catastrophic
AQA Exam Style

Practice Question

AQA 7517 — Paper 2 Style
(a) Explain the role of a Certificate Authority (CA) in securing HTTPS connections. [2]
(b) A user visits a website and sees a 'Not Secure' warning. Give TWO reasons why this warning might appear. [2]
(c) Explain what is meant by the 'chain of trust' in the context of digital certificates. [3]
(d) Explain how a digital certificate prevents a man-in-the-middle attack. [2]
[9 marks]
2 marks
(a) CA verifies the identity of the website owner [1] and digitally signs the certificate with its private key, binding the domain name to a public key [1]
2 marks
(b) Any 2: certificate not signed by a trusted CA / certificate expired / domain name doesn't match / certificate revoked / self-signed certificate
3 marks
(c) A root CA signs intermediate CA certificates [1]. Intermediate CA signs website certificates [1]. Browser trusts the root CA and can verify the chain back to it to trust the website certificate [1]
2 marks
(d) Attacker cannot obtain a valid certificate for the victim's domain from a trusted CA [1]. Browser rejects any certificate not signed by a trusted CA, so attack is detected [1]
Summary

Key Points to Remember

Digital certificate — binds a domain name to a public key; signed by CA
Certificate Authority — trusted third party that verifies identity and issues certificates
Chain of trust — root CA → intermediate CA → end certificate; browser trusts if root is pre-installed
MITM prevention — attacker can't fake a cert signed by a real CA
PKI = entire ecosystem of CAs, certificates, revocation — underpins HTTPS
🎉 Lesson complete — move to the quiz!