Public Key Infrastructure and Digital Certificates

Lesson plan

Level

Beginner

Time

About 65 minutes; the steps below add up to 67

Learners decide what makes a stranger’s identity card worth trusting, and what would make a public key believably the bank’s, before certificates are named. Predictions then precede designing a certificate, a CA’s two duties, who vouches for the CA, what a browser should check, self-signed leaves, sending the private key, a lookalike domain and the remedy for a failed CA; checks follow what a certificate binds, private keys, a private CA, root trust and wildcards. The habit to build: trace trust back to the trust store, and remember that a certificate proves control of a name, nothing more.

Objectives

• Explain what a certificate binds together and what it contains
• Describe certificate authorities, public and private
• Follow a chain from leaf to root, and why a root is trusted
• Describe validation, self-signed certificates, CSRs and the role of the SAN
• Explain what a certificate does not tell you, with the DigiNotar case

Before the lesson

• Open this page on your own screen and use “Open the lesson window” to open the lesson in a second window. Share only that second window.
• Learners need the Digital Signatures lesson first.
• If you show a real certificate, use a well-known public site and look only at its fields.
• The lesson takes about 67 minutes. To teach it in two parts, stop after “Self-signed certificates”; the second part opens with “Requesting a certificate: the CSR”.
• In presentation mode every step is shown in turns: Next reveals one moment, part or answer at a time, and the instructor view names what is on screen and what comes next.

Steps

1. Introduction Opening

   On screen: the lesson’s title, module and number; Next adds its objectives and key terms, as the lesson page lists them; Next again begins the first step.

   Objectives on screen

   • Explain what a certificate binds together and what it contains
   • Describe certificate authorities, public and private
   • Follow a chain from leaf to root, and why a root is trusted
   • Describe validation, self-signed certificates, CSRs and the role of the SAN
   • Explain what a certificate does not tell you, with the DigiNotar case

   Purpose: Learners decide what makes a stranger’s identity card worth trusting, and what would make a public key believably the bank’s, before certificates are named. Predictions then precede designing a certificate, a CA’s two duties, who vouches for the CA, what a browser should check, self-signed leaves, sending the private key, a lookalike domain and the remedy for a failed CA; checks follow what a certificate binds, private keys, a private CA, root trust and wildcards. The habit to build: trace trust back to the trust store, and remember that a certificate proves control of a name, nothing more.

2. 1. A stranger at the door Think 5 min

   Purpose: Raise the problem of trusting a public key through an identity card.

   Ask

   • What makes the card worth trusting?
   • What would make the key believably the bank’s?

   Responses to expect

   • “It looks official” is the first answer; push to who issued it.
   • On screen in turns: the opening question, its answer; then the question on whether the key is the bank’s, and its answer.

   Discussion pause: Ask what they would do to check the card before revealing.

   In the lesson window

   • Think it through: A stranger at your door says they are from the gas company and shows an identity card. You have never met them. What makes the card worth trusting, if anything?
   • Think it through: Your browser receives a public key that claims to be your bank’s. What would make you believe it really is?

3. 2. The idea Explain 5 min

   Purpose: Define a certificate, a CA and PKI, with the passport and its limits.

   Ask

   • What does a certificate bind together?

   Responses to expect

   • A public key and a name.
   • On screen in turns: the opening; then what a certificate says; the passport comparison; the check question on what a certificate binds, and its answer; where the comparison stops; PKI, the whole system.

   In the lesson window

   • Check your understanding: In the passport comparison, what does a certificate bind together?

4. 3. What is inside a certificate Predict 5 min

   Purpose: List the X.509 fields.

   Ask

   • What would you put on a certificate?
   • Is the private key inside?

   Responses to expect

   • Some think it is.
   • On screen in turns: the opening question, its answer; then the X.509 fields, with what each holds held back; what each field holds; the private key is not in the certificate; the check question on the private key, and its answer.

   Discussion pause: The field contents are held back: ask what each field should hold before revealing it.

   In the lesson window

   • Think it through: If you were designing a certificate, what would you put on it so that a browser could decide whether to trust it?
   • Check your understanding: Is the private key inside the certificate?

5. 4. Certificate authorities Predict 5 min

   Purpose: Describe a CA’s duties, and public and private CAs.

   Ask

   • What are the two duties?
   • Will a phone trust a private CA?

   Responses to expect

   • Many think every CA is trusted everywhere.
   • On screen in turns: the opening question, its answer; then a CA’s two duties; public and private CAs, starting with public; private; the check question on a private CA and a phone, and its answer.

   In the lesson window

   • Think it through: What two things must a certificate authority get right, one before issuing and one at all times?
   • Check your understanding: A company issues certificates from its own private CA. Will a visitor’s phone trust them?

6. 5. Root, intermediate and leaf certificates Predict 7 min

   Purpose: Follow the chain to the root and explain trust anchors and intermediates.

   Ask

   • Who vouches for the CA?
   • Why is a root trusted?

   Responses to expect

   • The self-signature is often taken as proof.
   • Diagram: start from the trust store, then reveal the root, the intermediate and the leaf; at each, ask who signed it.
   • On screen in turns: the opening; then the question on who vouches for the CA, and its answer; a chain of trust, starting with the trust store; the root; the intermediate; the leaf; why the root is trusted; a configuration decision; the check question on why a root is trusted, and its answer; why intermediates exist.

   Misconceptions to challenge

   • A learner may believe: “A self-signed root proves itself.” Respond: Being in the trust store is what makes it trusted.

   In the lesson window

   • Think it through: The bank’s certificate is signed by a CA. Who vouches for that CA? And who vouches for them?
   • Check your understanding: Why is a root certificate trusted?

7. 6. How a certificate is validated Predict 6 min

   Purpose: Walk through the browser’s validation step by step.

   Ask

   • What should the browser check?

   Responses to expect

   • Revocation is usually forgotten.
   • On screen in turns: the opening question, its answer; then Alice opens the bank’s site; what the browser checks, one step at a time; the diagram’s stages one at a time.

   In the lesson window

   • Think it through: Before sending anything private, what should Alice’s browser check about the bank’s certificate?

8. 7. Self-signed certificates Predict 4 min

   Purpose: Explain self-signed roots and leaves, and the click-through habit.

   Ask

   • Does a self-signed leaf encrypt? Does it prove identity?

   Responses to expect

   • It encrypts, but proves no identity.
   • On screen in turns: the opening; then the question on a self-signed website, and its answer; self-signed roots and leaves, starting with roots; leaves; where self-signed certificates are reasonable.

   In the lesson window

   • Think it through: A website’s own certificate is self-signed. Does the connection still encrypt? Does it prove who the site is?

9. 8. Requesting a certificate: the CSR Predict 5 min

   Purpose: Follow the CSR from key pair to installed certificate.

   Ask

   • Must the private key be sent?

   Responses to expect

   • Some think the CA needs it.
   • On screen in turns: the opening; then the question on sending the private key, and its answer; from key pair to certificate, starting with the key pair; creating the CSR; sending it; validation; issue; installation; the CA never needs the private key.

   Misconceptions to challenge

   • A learner may believe: “The CA needs the private key to issue a certificate.” Respond: Only the public key and names are sent.

   In the lesson window

   • Think it through: To get a certificate, must the server send its private key to the CA?

10. 9. Common Name and Subject Alternative Name Explain 5 min

    Purpose: Explain the SAN, its precedence over the CN, and wildcards.

    Ask

    • Does a wildcard cover the bare domain?

    Responses to expect

    • No: only names one level below.
    • On screen in turns: the opening; then the Subject Alternative Name; browsers match the SAN; the check question on a wildcard’s scope, and its answer; SAN lists and wildcards, starting with lists; wildcards; Common Name and SAN, side by side.

    In the lesson window

    • Check your understanding: Does a wildcard for every name one level below harbourbank.example also cover harbourbank.example itself?

11. 10. What a certificate does not tell you Predict 4 min

    Purpose: Separate control of a name from honesty.

    Ask

    • Will a lookalike domain show a padlock?

    Responses to expect

    • Most say no.
    • On screen in turns: the opening question, its answer; then a CA does not certify safety; what a valid certificate tells you; a look-alike domain with a valid certificate; domain, organisation and extended validation.

    Misconceptions to challenge

    • A learner may believe: “A valid certificate means the site is safe.” Respond: It proves control of the name only.

    In the lesson window

    • Think it through: A criminal registers harbourbnak.example and obtains a valid certificate for it. Will the browser show a padlock?

12. 11. When a certificate authority fails: DigiNotar Predict 5 min

    Purpose: Use DigiNotar to show that every trusted CA is a single point of failure.

    Ask

    • What could browser makers do?

    Responses to expect

    • Remove the roots.
    • On screen in turns: the opening; then DigiNotar; the question on the remedy, and its answer; the roots were removed; what the case shows, starting with the least careful CA; CA signing systems as targets; a trust-anchor decision; stronger defences since; looking at real certificates.

    If the explanation does not land: Compare it with a passport office found issuing fake passports: every passport it ever issued becomes suspect.

    To go further

    • How do public logs of every issued certificate help a domain owner notice a fraudulent one?

    In the lesson window

    • Think it through: A trusted CA has issued fraudulent certificates for famous websites. What could browser makers do about it?

13. 12. Security+ terminology Explain 1 min

    Purpose: Link the lesson to the Security+ wording.

    Ask

    • Which objective terms appear here?

    Responses to expect

    • CAs, CSRs, self-signed and wildcard certificates, root of trust.
    • On screen in turns: the opening; then what the objectives call things, and do not name.

14. 13. Apply it in a new situation Apply 4 min

    Purpose: Set up independent application, ideally on a later day.

    Ask

    • Who will try these now, and who later in the week?

    Responses to expect

    • The warning tests habits; the offline root tests intermediates; the CN tests the SAN.
    • On screen in turns: the opening; then the question on a click-through habit, and its answer; the question on keeping the root offline, and its answer; the question on a name in the Common Name only, and its answer.

    In the lesson window

    • Apply it: Staff see a certificate warning on an internal site every day and have learned to click through it. What is the danger?
    • Apply it: Why is a root CA’s private key usually kept offline, with day-to-day signing done by an intermediate?
    • Apply it: A new certificate lists the site’s name only in the Common Name. What will modern browsers do?

15. 14. Check your understanding Check 4 min

    Purpose: Check the lesson against the approved revision-bank questions.

    Ask

    • Answer individually, then compare before revealing.

    Responses to expect

    • The chain questions link to the root step.
    • On screen in turns: the opening; then the revision questions one at a time, each followed by its answer; where to practise next.

16. 15. What to remember Consolidate 2 min

    Purpose: Summarise the five points, the key terms and the misunderstandings.

    Ask

    • Without looking: why is a root trusted?

    Responses to expect

    • Because it is in the trust store.
    • On screen in turns: the opening; then the summary; the key terms; the common misunderstandings.

17. Lesson recap Closing

    On screen: the lesson’s objectives again; Next adds the closing question, which asks the class to explain each one in their own words without looking back. It says nothing about what anyone has learnt: use the answers to decide what to revisit.

    Points to listen for

    • A key bound to a name, signed by a CA.
    • Trust runs up to the trust store.
    • Check name, dates, chain and revocation.
    • The private key never travels.
    • A name, not honesty; every CA matters.

Consolidation

• A key bound to a name, signed by a CA.
• Trust runs up to the trust store.
• Check name, dates, chain and revocation.
• The private key never travels.
• A name, not honesty; every CA matters.