Skip to content

07-04: Exercises

Question

You are given a simplified 3-certificate chain presented by a server for www.example.com:

Certificate 1 (leaf): - Subject: CN=www.example.com - Issuer: CN=Example Intermediate CA

Certificate 2 (intermediate): - Subject: CN=Example Intermediate CA - Issuer: CN=Example Root CA

Certificate 3 (root): - Subject: CN=Example Root CA - Issuer: CN=Example Root CA (self-signed) - Present in the browser's trusted root store

  1. Is this chain valid? Walk through how a browser would check it.
  2. Now suppose Certificate 2's Subject is instead CN=Some Other CA, with everything else unchanged. What breaks, and where?
  3. Would the chain in Question 1 be enough on its own to let the browser show a padlock with no warnings? What else does the browser separately need to check?

Solution

Step 1: Walking a valid chain

Chain validation works by matching each certificate's Issuer field to the next certificate's Subject field, going up toward a trusted root (see 07-08: Digital Certificates & PKI):

  1. Leaf's Issuer (Example Intermediate CA) matches Certificate 2's Subject (Example Intermediate CA). ✔️ Link 1 holds.
  2. Certificate 2's Issuer (Example Root CA) matches Certificate 3's Subject (Example Root CA). ✔️ Link 2 holds.
  3. Certificate 3 is self-signed (Subject == Issuer) and is present in the browser's trusted root store. ✔️ The chain terminates at a trusted anchor.

At each link, the browser would also cryptographically verify that the lower certificate's signature was actually produced using the upper certificate's private key (not just that the names happen to match textually) — but assuming that check passes too, this chain is structurally valid.

👉 (1) Yes, this chain is valid — each Issuer/Subject pair links correctly, and it terminates at a trusted root.

Step 2: Breaking the chain

If Certificate 2's Subject changes to CN=Some Other CA, then:

  • The leaf's Issuer still says CN=Example Intermediate CA.
  • But Certificate 2's Subject is now CN=Some Other CA.
  • These no longer match.

The browser cannot link the leaf certificate to Certificate 2 anymore — as far as chain-building logic is concerned, Certificate 2 doesn't correspond to whoever issued the leaf. Link 1 breaks. Even though Certificate 2 → Certificate 3 (the second link) is still fine on its own, a broken first link means the whole chain fails to build, and the browser cannot trace the leaf certificate back to any trusted root. The connection would be flagged as untrusted.

👉 (2) The Issuer field on the leaf no longer matches the Subject field on Certificate 2, breaking the chain at that link — the browser can no longer connect the leaf to the trusted root, regardless of whether the rest of the chain above it is fine.

Step 3: Chain validity isn't the only check

Per 09-04: Certificates in Practice, a browser performs two distinct kinds of checks, and both must pass:

  1. Chain validation (what we just did) — proves the certificate was legitimately issued by a CA the browser trusts.
  2. Hostname validation — separately checks that the domain the user is actually visiting matches the certificate's Subject/SAN fields.

A perfectly valid chain for www.example.com does not grant a padlock if the user is actually visiting www.different-site.com — that's a completely separate check. The browser would also need to confirm the certificate hasn't expired (validity dates) and hasn't been revoked (via OCSP or a revocation list).

👉 (3) No — a structurally valid chain is necessary but not sufficient. The browser must also independently verify the hostname matches, confirm the certificate is within its validity period, and check revocation status before showing a fully trusted connection.

Final Answer

  • The original 3-certificate chain is valid: each Issuer matches the next certificate's Subject, terminating at a trusted root.
  • Changing Certificate 2's Subject breaks the link between the leaf and the intermediate certificate, invalidating the whole chain regardless of the rest.
  • Chain validity alone isn't sufficient — hostname matching, expiration dates, and revocation status are separate, equally required checks.