📜Module 03 — Inside an X.509 Certificate

    0:d=0  hl=4 l=1367 cons: SEQUENCE
    4:d=1  hl=4 l=1087 cons: SEQUENCE
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=  16 prim: INTEGER           :0F2E5D8A47B1C93064E8F1A2B7D30C45
   31:d=2  hl=2 l=  10 cons: SEQUENCE

--- and the very end of the file ---
 1095:d=1  hl=2 l=  10 cons: SEQUENCE
 1097:d=2  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA384
 1107:d=1  hl=4 l= 262 prim: BIT STRING

What to read out of this.

• Look at the d= column. d=0 is the outer box. Everything at d=1 is a direct child of it — and there are exactly three: the SEQUENCE at offset 4 (that is tbsCertificate, 1087 bytes of it), the SEQUENCE at offset 1095 (that is signatureAlgorithm), and the BIT STRING at offset 1107 (that is signatureValue).
• The whole certificate is 1367 bytes and the signed part is 1087 of them. The remaining 280 bytes are the algorithm name and the signature itself — roughly a fifth of the file is the signature.
• BIT STRING is always the signature. When you see a large BIT STRING as the last item at d=1, that is it. There is no other candidate.
• cont [ 0 ] at offset 8 holding INTEGER :02 is the version field, and 02 means version 3. Yes, the numbering is off by one — that is section A2.

⚠️ Your numbers will not match mine. Serial, lengths and algorithm depend on which certificate you downloaded and when. What must match is the shape: three children at d=1, with a BIT STRING last.

4:        Signature Algorithm: ecdsa-with-SHA384
26:    Signature Algorithm: ecdsa-with-SHA384

What to read out of this — it looks like a duplication bug and it is not.

• Line 4 is inside tbsCertificate. It is part of the signed data, so an attacker cannot change it without breaking the signature.
• Line 26 is outside, sitting on its own as part 2 of the three-part structure. It is not covered by the signature, so an attacker can change it freely.
• So why have the unprotected one at all? Because a verifier has a chicken-and-egg problem: to check the signature it must first know which algorithm to use, and it needs that before it can verify anything. The outer copy is a hint that lets verification start.
• And that is exactly why the inner copy exists too. A correct verifier checks that the two match. If they differ, the certificate is rejected. The unprotected hint gets you started; the protected copy proves the hint was honest.

🔑 This is a small, sharp thing to have ready in an interview. "Why is the signature algorithm listed twice?" is a question that separates people who have actually read a certificate from people who have only read about certificates. The answer — one copy to bootstrap verification, one copy inside the signed data to prove the first was not tampered with — takes fifteen seconds and lands well.

💡 Historically, mismatches here were a genuine attack surface. An attacker who could downgrade the outer algorithm to something weak, and whose target did not compare the two, could get a forged certificate accepted. Modern libraries all compare them. It is a good example of a rule that exists because somebody once exploited its absence.

Structurally it is three parts: tbsCertificate (everything meaningful, and the only part that is signed), signatureAlgorithm, and signatureValue.

Inside tbsCertificate, the fields that matter day to day are: version (v3 in practice), serial number, issuer, validity (notBefore/notAfter), subject, subjectPublicKeyInfo — the public key and its algorithm — and then the extensions, which is where SAN, key usage, basic constraints, AIA and CRL distribution points live.

The detail that shows you have opened one: the extensions are where nearly all the actual behaviour is defined. The base fields tell you who and when; the extensions tell you what the certificate is allowed to do, and those are the ones that cause real outages.

The issuer's — the CA's. Never the subject's.

That is what makes a certificate meaningful: it is a statement by a third party, not a claim you make about yourself. Signing your own certificate proves nothing, which is precisely why a self-signed certificate is trusted by nobody except whoever explicitly installs it.

The follow-on worth volunteering: this is also why a certificate is a public document, safe to hand to anyone. It contains your public key and someone else's signature. There is no secret of yours anywhere in it — which is why the private key lives in a completely separate file that never leaves the server.

Once inside tbsCertificate (covered by the signature, therefore tamper-proof) and once outside it (not covered, therefore modifiable).

The outer copy solves a bootstrapping problem — a verifier must know which algorithm to use before it can verify anything. The inner copy is the authoritative one. A correct implementation compares them and rejects the certificate if they disagree.

Why it exists at all: an attacker who could substitute a weaker outer algorithm, against a verifier that did not compare, had a real forgery path. Every modern library compares. It is a good illustration that in TLS, "redundant" fields usually exist because someone attacked their absence.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:

--- serial on its own ---
serial=0F2E5D8A47B1C93064E8F1A2B7D30C45
32

--- now compare with a root CA certificate ---
serial=008210CFB0D240E3594463E0BB63828B00

What to read out of this.

• Version: 3 (0x2) — the name and the stored value, side by side. Every certificate you meet in practice says this.
• 32 hex characters = 16 bytes = 128 bits. Comfortably above the 64-bit floor. Public CAs generally issue well past the minimum, because the minimum is a floor, and sitting exactly on a floor is how you end up below it.
• The root's serial starts with 00. That leading zero byte is not decoration — DER integers are signed, so a value whose first bit is 1 would be read as negative. A 00 byte is prepended to keep it positive. You will see this on roughly half of all serials, and it is a nice small thing to be able to explain.
• Serial numbers are per-issuer, not global. The pair (issuer, serial) is what uniquely identifies a certificate — which is exactly how revocation lists refer to certificates, as you will see in Module 09.

💡 The story worth knowing, because interviewers love it. In early 2019 it emerged that a widely used CA product, EJBCA, had an off-by-one: it was configured for 64 bits of randomness but the first bit was always forced to zero, leaving 63. One bit short of the requirement.

The certificates were perfectly safe in practice. But the Baseline Requirements say 64, and a certificate that violates the BRs is mis-issued by definition and must be revoked within five days. The result was a mass revocation affecting millions of certificates, and a very bad fortnight for a lot of operations teams.

The lesson to voice: in public PKI, compliance failures cause outages just as reliably as security failures do. "It is not actually exploitable" is not a defence — the certificate still gets revoked.

To stop an attacker predicting what the CA is about to sign.

A signature covers the hash of the certificate body. If an attacker can construct two certificates that hash identically, a signature on the harmless one is also valid on the dangerous one. Building that collision requires knowing the exact bytes the CA will produce — and with a sequential serial and a predictable timestamp, they largely do. This was demonstrated for real against MD5 in 2008, producing a rogue CA certificate.

Random serial bytes make the content unguessable, so the collision cannot be prepared in advance. The CA/Browser Forum has required at least 64 bits of CSPRNG output since Ballot 164 took effect in September 2016.

The example that shows you follow the industry: the 2019 EJBCA incident, where a configuration produced 63 bits instead of 64. Not exploitable, but a Baseline Requirements violation — so millions of certificates had to be revoked within five days. In public PKI, compliance failure and outage are the same event.

No — unique per issuing CA. The identifier that is unique is the pair (issuer, serial number).

This matters operationally because that pair is exactly how a CRL identifies a revoked certificate, and how OCSP requests are formed. A serial alone is not enough to look anything up.

A related detail worth having: serials are DER INTEGERs, which are signed, so a serial whose leading bit is 1 gets a 00 byte prepended to keep it positive. That is why so many serials you see start with 00, and why the printed hex is sometimes one byte longer than you expect.

notBefore=Jan 15 00:00:00 2026 GMT
notAfter=Apr 16 23:59:59 2026 GMT

--- how many days left? ---
expires: Apr 16 23:59:59 2026 GMT
days remaining: -125

--- a root CA lives much longer ---
notBefore=Jun  4 11:04:38 2015 GMT
notAfter=Jun  4 11:04:38 2035 GMT

--- the raw encoding: which time type is used? ---
  110:d=4  hl=2 l=  13 prim: UTCTIME           :260115000000Z
  125:d=4  hl=2 l=  13 prim: UTCTIME           :260416235959Z
  118:d=4  hl=2 l=  13 prim: UTCTIME           :150604110438Z
  133:d=4  hl=2 l=  13 prim: UTCTIME           :350604110438Z

What to read out of this.

• 260115000000Z is 15 January 2026 — a two-digit year, exactly as the table said. 35 in the root's date means 2035. Both are safely under 2050, so both use UTCTime.
• notAfter is 23:59:59, not midnight. CAs habitually set expiry to the last second of a day. Worth knowing when you are computing "days remaining" and your number seems off by one.
• The leaf lives about 90 days; the root lives 20 years. That gap is the whole shape of PKI: the root is protected by being offline and rarely used, so it can afford a long life. The leaf is on an internet-facing server, so it must be replaced constantly.
• The days remaining arithmetic works on Linux but not macOS — BSD date does not accept -d. On macOS use date -j -f, or install coreutils and use gdate. Small portability trap that bites people writing expiry monitoring scripts.

💡 Notice that the certificate does not say how long it is valid for — only when it starts and when it stops. "90-day certificate" is a description of the gap, not a field. Nothing in the file records an intended lifetime.

Certificate will expire
exit code: 1

Certificate will expire
exit code: 1

Certificate will not expire
exit code: 0

What to read out of this.

• Exit code 0 means "safe", exit code 1 means "expiring or expired". That is the opposite of what many people guess, so check it rather than assuming — a monitoring script with the sense inverted reports everything as healthy, forever, and nobody notices until the outage.
• -checkend cannot tell you "already expired" versus "expires soon". Both give exit code 1 and the same message. If you need to distinguish them, run -checkend 1 as well: if that also fails, it is already dead.
• The message goes to stdout and is meant for humans. In a script, use the exit code and throw the text away.

🔑 The check worth putting in your own toolbox, and worth being able to write on a whiteboard:

for host in example.com api.example.com www.example.com; do
  end=$(openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  if openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
     | openssl x509 -noout -checkend 2592000 >/dev/null; then
    printf '%-24s OK      (until %s)\n' "$host" "$end"
  else
    printf '%-24s WARNING (expires %s)\n' "$host" "$end"
  fi
done

Now imagine this at 500 hosts. Two things go wrong with home-grown expiry monitoring, and both are worth naming in an interview:

1. It checks the file on disk, not what the server is actually serving. Those differ whenever a renewal wrote a new file but nothing reloaded the service — which is the single most common certificate outage there is.
2. It checks only the leaf. Intermediates expire too, and a bundle can contain a perfectly valid leaf sitting behind an expired intermediate. Any check worth having walks the whole chain, which is Module 05.

Nothing changes technically — the key still works and the crypto is unchanged. What changes is that clients refuse the connection. Browsers show a full interstitial; API clients and mobile apps typically fail outright with no user able to click through. So an expiry is a total outage, not a degradation.

Management, in order of how much it actually helps:

1. Automate issuance and renewal — ACME, cert-manager, or the cloud provider's managed certificates. This is the only real fix; everything else is mitigation.
2. Monitor what the server is serving, not the file on disk, and alert on the whole chain rather than just the leaf.
3. Alert with enough lead time to act — 30 days, then 7, then daily.
4. Reload after renewal. A renewed file that no process has picked up is the most common cause of "but we renewed it".

The 2026 context worth raising unprompted: the CA/Browser Forum has adopted a schedule cutting maximum certificate lifetime to 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Manual renewal is being deliberately engineered out of existence. If a team is still renewing by hand, that is now a dated deadline rather than a preference.

The client's clock, not the certificate.

CAs routinely backdate notBefore by an hour or more precisely because client clocks drift, so a certificate that is genuinely not yet valid is rare. A client reporting it is usually a device with no RTC battery, a VM restored from a snapshot, a container with a bad clock, or an appliance that never had NTP configured.

Confirm with openssl x509 -noout -dates on the certificate and date -u on the client. If the certificate's notBefore is in the past by UTC, the client is wrong.

Worth adding: this is why embedded and IoT fleets have such trouble with TLS. A device that boots with its clock at the epoch cannot validate any certificate at all, which is why those systems often need a trusted time source before they can do anything else.

Because revocation does not work reliably (Module 09 covers exactly why). If you cannot depend on withdrawing a compromised certificate, the next best thing is to make sure it stops working on its own, soon.

Short lifetimes also force automation, and automation removes the manual steps where mistakes and outages come from. Certificates went from 5 years, to 3, to 2, to 398 days, to 200 days in March 2026, with 100 days scheduled for 2027 and 47 days for 2029.

The framing that shows judgement: shorter lifetimes trade a rare catastrophic risk for a frequent routine operation. That is a good trade only if the routine operation is automated. For a team renewing by hand it makes things strictly worse, which is precisely the pressure the industry intends to apply.

=== the live server certificate ===
subject=CN = example.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1

=== a root CA certificate ===
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

=== the same names, broken into separate fields ===
subject=
    commonName                = example.com

What to read out of this — the second block is the important one.

• On the root certificate, Subject and Issuer are identical. That is the definition of a self-signed certificate: it says it issued itself. Every root CA in your trust store looks like this, and it is how you recognise a root at a glance without reading anything else.
• This also explains why a chain has to stop. Each certificate points at its issuer, and you follow the pointers upward. A self-signed certificate points at itself, so the trail ends. It is trusted not because of its signature but because it is on the list — the border-control list from Module 01.
• The live certificate has almost nothing in its Subject — just a CN. That is completely normal for a modern DV certificate. There is no O, because nobody verified who owns the company; only control of the domain was checked.
• -nameopt multiline splits the DN into its labelled fields, which is much easier to read when a DN is long. Worth remembering when you are staring at a wall of comma-separated text.

⚠️ If your issuer says something unexpected — the name of your employer, a security appliance vendor, or anything that is not a public CA — you are behind a TLS-inspecting proxy. Your organisation's middlebox is terminating the connection, reading it, and re-issuing a certificate signed by a private CA that was installed on your machine. This is the man-in-the-middle from Module 01 (Part C1), running with permission.

It is worth checking now, because if it applies to you then every live-site exercise in this track will show you the proxy's certificate rather than the real one. The structure will still be right; the names, serials and dates will not be. Use the root certificate from your own trust store for the exercises where exact values matter.

Start with Subject and Issuer:

• Root: Subject equals Issuer — it is self-signed, and it is trusted because it is in the trust store, not because of who signed it.
• Intermediate: Subject differs from Issuer, and basicConstraints says CA:TRUE — it is allowed to sign further certificates.
• Leaf: Subject differs from Issuer, and basicConstraints says CA:FALSE or is absent — it is the end of the line.

The precision that matters: "self-signed" and "root" are not synonyms. A self-signed certificate you generated this morning is self-signed but is not a root, because nothing trusts it. Being a root is about being in a trust store, which is a decision made elsewhere, not a property of the file.

Organisational Unit — a department or team name inside the organisation. It was prohibited in publicly trusted TLS certificates by the CA/Browser Forum from September 2022.

The reason is clean: no CA ever verified it. A field that anybody could put anything into, displayed alongside verified fields, is worse than no field — it lends unearned credibility. Rather than build a verification process for it, the industry removed it.

The general principle worth voicing: public PKI has been steadily deleting anything it cannot actually check. Same logic retired EV's green address bar, and the same logic is behind the move to short-lived, domain-validated-only certificates.

subject=CN = *.badssl.com
X509v3 Subject Alternative Name:
    DNS:*.badssl.com, DNS:badssl.com

=== now ask OpenSSL to actually CHECK the hostname ===
Verification error: Hostname mismatch
Verify return code: 62 (Hostname mismatch)

What to read out of this — there are three separate lessons here.

1. The mismatch is real and precise. The certificate covers *.badssl.com and badssl.com. You asked for wrong.host.badssl.com. A wildcard replaces exactly one label, so *.badssl.com covers foo.badssl.com but not wrong.host.badssl.com, which has two labels below the domain. That is section B3.

2. The first command reported no error at all. Read that again — it printed the certificate quite happily. openssl s_client does not check the hostname by default. You must ask for it with -verify_hostname. This surprises people, and it matters: a script that uses s_client to "test TLS" and only checks the exit code is not testing hostname validity at all.

3. Verify return code: 62 is worth memorising. The numeric codes are stable and greppable, which makes them far better than message text for automation:

🔑 Codes 20 and 62 between them account for the overwhelming majority of real TLS failures. 20 means the chain is incomplete — you served the leaf without its intermediates. 62 means the certificate is fine but is for a different name. Recognising those two on sight will make you noticeably faster than most people at diagnosing a broken deployment.

⚠️ If you are behind a corporate TLS-inspecting proxy, this exercise will show Verification: OK — because the proxy re-issued a certificate that does match the name you asked for. If that happens to you, it is not a broken exercise; it is a live demonstration of exactly what an inspecting middlebox does.

CN is a single free-text label inside the Subject DN. SAN is a proper extension holding a typed list of identities — DNS names, IP addresses, email addresses, URIs.

Clients use SAN, and only SAN. The old CN fallback was removed from Chrome in 2017, and RFC 9525 — which obsoleted RFC 6125 in November 2023 — states outright that the Common Name RDN must not be used to identify a service. A certificate with a perfect CN and no SAN matches nothing.

Why CN persists: habit and human readability. CAs still populate it, tools still display it, and it is convenient as a short label. It simply has no security meaning any more.

The practical symptom to name: internally generated certificates made from an old openssl req command with no SAN configured. They look right, openssl x509 -subject shows the correct hostname, and every modern client rejects them with ERR_CERT_COMMON_NAME_INVALID. The fix is to add SAN, not to change the CN.

First establish what the certificate actually covers, rather than what it was supposed to cover:

openssl s_client -connect host:443 -servername host </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

Then work out which of the four causes it is:

1. The name genuinely is not in the SAN list — reissue with the correct names.
2. A wildcard depth problem — *.example.com does not cover a.b.example.com, and does not cover bare example.com either.
3. The wrong certificate is being served — usually an SNI or virtual-host misconfiguration, where the default server block answers instead of the intended one. Test by comparing the certificate returned with and without -servername.
4. The certificate has no SAN at all — an internally generated one. Modern clients reject it outright regardless of CN.

The diagnostic that separates causes 1 and 3 quickly: request the same host with and without -servername. If the certificate differs, it is a server-selection problem, not an issuance problem — and the fix is in the web server config, not at the CA.

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

=== a certificate covering many names ===
X509v3 Subject Alternative Name:
DNS:*.wikipedia.org
DNS:wikipedia.org
DNS:*.m.wikipedia.org
DNS:*.wikimedia.org
DNS:wikimedia.org
DNS:*.m.wikimedia.org
DNS:*.wikibooks.org
DNS:wikibooks.org
DNS:*.wiktionary.org
DNS:wiktionary.org

=== how many names in total? ===
52

What to read out of this.

• Look at the pairs. *.wikipedia.org and wikipedia.org. *.wikimedia.org and wikimedia.org. Every single time. That is rule 3 from the callout above, visible in production: the wildcard does not cover the bare domain, so the bare domain is listed separately.
• *.m.wikipedia.org is a second wildcard at a deeper level, listed explicitly. Rule 1 again — one star cannot reach two levels down, so if you need depth you buy another entry.
• 52 names on one certificate. This is completely normal for a large site, and it is worth understanding the trade-off: one certificate covering 52 names means one renewal to manage, but also means one mistake takes down all 52, and every one of those names is published together in the Certificate Transparency logs for anyone to read (Module 11).
• The output is one long comma-separated line, which is why the tr ',' '\n' is there. Worth keeping in your notes; the raw form is unreadable once you get past about six names.

en.wikipedia.org         wc-00.pem: OK
wikipedia.org            wc-00.pem: OK
a.b.wikipedia.org        error 62 at 0 depth lookup: Hostname mismatch
www.example.org          error 62 at 0 depth lookup: Hostname mismatch

What to read out of this — this is the wildcard rule table, proven rather than asserted.

• en.wikipedia.org → OK. One label replaced by the star. This is what a wildcard is for.
• wikipedia.org → OK, but not because of the wildcard. The star does not cover the bare domain. It passed because wikipedia.org is listed as its own separate DNS: entry. Remove that entry and this line would fail. This is the single most misunderstood point about wildcards, and here it is demonstrated.
• a.b.wikipedia.org → error 62. Two labels below the domain. One star, one label. No match.
• www.example.org → error 62. Not in the list at all, which is the ordinary case.

💡 openssl verify -verify_hostname is an underused tool. It answers "would a client accept this certificate for this name?" with no server and no network, which makes it perfect for testing a certificate before you deploy it. Far better than deploying and then trying it in a browser.

Now imagine this at 500 hosts. Wildcards are attractive because they mean one renewal instead of five hundred. The costs are worth being able to state:

1. One private key protects every name. A compromise on the least important host compromises all of them.
2. The key ends up everywhere. A wildcard certificate is by definition copied onto many machines, which multiplies the chance of it leaking.
3. One mistake is a total outage. A bad renewal takes down every service at once, rather than one.
4. A wildcard cannot be scoped. You cannot hand *.example.com to a team and restrict them to their subdomain.

The modern alternative is short-lived, per-host, automatically issued certificates — cheap when issuance is automated, which is the whole argument of Module 10.

A certificate whose SAN contains an entry like *.example.com, matching any single label in that position — shop.example.com, api.example.com, and so on.

The rules, stated precisely: the star replaces exactly one label, must be the leftmost label, and does not cover the bare domain. That last point is why real wildcard certificates almost always list both *.example.com and example.com as separate SAN entries.

Use one when you have many subdomains, they are genuinely under one team's control, and per-host issuance is impractical — for example subdomains created dynamically per customer, where you cannot request a certificate in advance.

The trade-offs to raise unprompted: one key protecting every name, that key copied onto many machines, one bad renewal taking down everything at once, and no way to scope the certificate to a single team. With ACME automation, per-host certificates are usually the better answer — and with lifetimes dropping to 47 days by 2029, the operational argument for wildcards is weakening rather than strengthening.

No. The wildcard replaces a label, and in the bare domain there is no label in that position to replace.

This is why production wildcard certificates carry both entries. It is also a frequent cause of "the site works at www but not at the apex" — the wildcard is present, the bare domain was never added.

Nor does it cover a.b.example.com — one star, one label. Deeper subdomains need their own entry, which is why you see *.m.example.com listed alongside *.example.com on large sites.

Because IP addresses need an IP Address: SAN entry. A DNS: entry containing what looks like an IP does not match — the types are distinct and are compared differently.

Public CAs will issue certificates for public IPs, but only after validating control of the address, and it is uncommon. For internal services connected to by IP, this is a normal requirement of your private CA.

The better question to raise: connecting by IP means you cannot use SNI, cannot move the service without reissuing, and cannot use a load balancer sensibly. The usual fix is not to add an IP SAN but to give the service a DNS name — and if an interviewer is asking this, they are often probing whether you push back on the design or just satisfy the request.

X509v3 extensions:
    X509v3 Authority Key Identifier:
        8A:23:EB:9E:6B:D7:F9:37:5D:F9:6D:21:39:76:9A:A1:67:DE:10:A8
    X509v3 Subject Key Identifier:
        C4:7D:3B:19:E0:5A:82:F1:6D:B4:09:C7:3E:88:12:0B:5A:F3:96:D2
    X509v3 Subject Alternative Name:
        DNS:example.com, DNS:www.example.com
    X509v3 Key Usage: critical
        Digital Signature
    X509v3 Extended Key Usage:
        TLS Web Server Authentication, TLS Web Client Authentication
    X509v3 CRL Distribution Points:
        Full Name:
          URI:http://crl3.digicert.com/DigiCertGlobalG3TLSECCSHA3842020CA1-1.crl
    X509v3 Certificate Policies:
        Policy: 2.23.140.1.2.1
    Authority Information Access:
        OCSP - URI:http://ocsp.digicert.com
        CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalG3TLSECCSHA3842020CA1-1.crt
    X509v3 Basic Constraints: critical
        CA:FALSE
    CT Precertificate SCTs:
        Signed Certificate Timestamp:
            Version   : v1 (0x0)
            Log ID    : 7D:59:1E:12:E1:78:2A:7B:...

What to read out of this.

• Exactly two extensions say critical: Key Usage and Basic Constraints. Everything else is advisory. That is deliberate and near-universal — these two are the ones that must never be ignored, because getting them wrong is a security failure rather than an inconvenience.
• Basic Constraints: critical / CA:FALSE is the certificate stating flatly: I am not a CA, and you must not treat me as one. Section C2 explains why that sentence exists.
• Notice what is NOT critical: Subject Alternative Name. That surprises people, because SAN is the most security-relevant field there is. The reason is that clients are required by other rules to check it, so marking it critical would add nothing while breaking older software.
• Every extension here is one of the next five sections. You already know SAN. AKI/SKI is C4, Key Usage and EKU are C3, Basic Constraints is C2, CRL DP and AIA are C5, Policies and SCTs are C6.

💡 A faster way to pull out just one extension, worth putting in your notes:

openssl x509 -in live.pem -noout -ext subjectAltName
openssl x509 -in live.pem -noout -ext basicConstraints,keyUsage,extendedKeyUsage

It means: if you do not understand this extension, you must reject the certificate. Non-critical means: if you do not understand it, ignore it.

The flag exists so the ecosystem can evolve. A new non-critical extension is invisible to old clients, so it deploys safely everywhere; a critical one is only accepted by clients that implement it.

In practice the two extensions you will consistently see marked critical on a server certificate are Key Usage and Basic Constraints — the two whose misinterpretation is a security failure rather than a cosmetic one.

The observation worth adding: SAN is deliberately not critical, even though it is the most security-relevant extension. Clients are obliged to check it by separate rules, so marking it critical would gain nothing and break older software. It is a good illustration that "critical" is about handling unknown extensions, not about how important a field is.

=== ch-00.pem ===
subject=CN = example.com
X509v3 Basic Constraints: critical
    CA:FALSE

=== ch-01.pem ===
subject=C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020
X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0

=== root.pem ===
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
X509v3 Basic Constraints: critical
    CA:TRUE

What to read out of this — the three lines tell the whole story of a chain.

• The leaf says CA:FALSE. It is a traveller. If it ever signs another certificate, that signature must be ignored by every correct client. This one boolean is what stops the 2002 attack.
• The intermediate says CA:TRUE, pathlen:0. It may issue certificates, but nothing below it may be a CA. That is a deliberate limit: it means a compromise of this intermediate lets an attacker mint leaf certificates, but not create a whole new CA hierarchy underneath. Damage is bounded.
• The root says CA:TRUE with no pathlen — unlimited depth, which is appropriate because the root's job is to delegate. Its protection is not a path limit; it is that the private key lives offline in a safe and is used a handful of times a year.
• All three are marked critical. No client is permitted to skip this field.

🔑 pathlen:0 on an intermediate is the shape of a well-designed PKI, and worth saying out loud in an interview: "limit the blast radius at every level — the root delegates to intermediates, and the intermediates are explicitly forbidden from delegating further."

It states whether the certificate is a CA (CA:TRUE) or an end entity (CA:FALSE), and optionally limits how many further CA levels may appear beneath it (pathlen).

It is critical because ignoring it collapses the entire trust model. If a client does not enforce CA:FALSE, then any certificate becomes a CA — anyone holding a legitimate certificate for their own site can sign one for your bank, and it chains to a trusted root with no warning.

The example that makes it concrete: that is not hypothetical. Internet Explorer and Microsoft's CryptoAPI did exactly this until 2002, disclosed by Mike Benham as CVE-2002-0862. The whole web's security rested on a boolean a major browser was not reading.

The design point worth adding: well-run PKIs set pathlen:0 on issuing intermediates, so that a compromised intermediate can mint leaf certificates but cannot create a new CA hierarchy. It bounds the blast radius one level down.

=== ch-00.pem ===          (the leaf)
X509v3 Key Usage: critical
    Digital Signature
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

=== ch-01.pem ===          (the intermediate)
X509v3 Key Usage: critical
    Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

=== root.pem ===
X509v3 Key Usage: critical
    Digital Signature, Certificate Sign, CRL Sign
No extensions in certificate

What to read out of this.

• The leaf has Digital Signature and nothing else. It cannot sign certificates, cannot sign CRLs. Even if basicConstraints were somehow ignored, Key Usage independently forbids it from acting as a CA. Two separate controls, both saying no. That belt-and-braces design is a direct consequence of the 2002 bug.
• The intermediate adds Certificate Sign and CRL Sign. That is what makes it a working CA. basicConstraints: CA:TRUE says it may be a CA; keyCertSign says its key may perform the signing. Both are required — one without the other does not work.
• The intermediate also carries EKU serverAuth, clientAuth. On a CA this acts as a ceiling: it constrains what the certificates it issues may be used for. An intermediate limited to serverAuth cannot be used to mint code-signing certificates, which is a valuable containment property.
• No extensions in certificate on the root's EKU line just means the extension is absent, not that the root has no extensions at all. Roots usually omit EKU deliberately, because a root should not constrain what its whole hierarchy may do.

💡 The most common real symptom of an EKU problem: a certificate that works fine for a server but is rejected when you try to use it for client authentication in mutual TLS. It is missing clientAuth, and the error rarely says so clearly — you usually get a generic handshake failure. If mutual TLS fails and everything else looks right, check EKU first.

Key Usage restricts the cryptographic operations the key may perform — digitalSignature, keyEncipherment, keyCertSign, cRLSign. Extended Key Usage restricts the purposes the certificate may serve — serverAuth, clientAuth, codeSigning, emailProtection.

One is about what the key can do; the other is about what the certificate is for. Both must permit an operation for it to be allowed.

The example that shows it clearly: a CA certificate needs keyCertSign in Key Usage to sign anything at all, and basicConstraints: CA:TRUE to be recognised as a CA. Two independent controls guarding the same thing — deliberate redundancy, because a single check failed catastrophically in 2002.

Not any more. keyEncipherment was required for RSA key transport, where the client encrypted the pre-master secret to the server's public key. TLS 1.3 removed key transport completely.

In TLS 1.3 every handshake uses ephemeral Diffie-Hellman for key exchange, and the certificate's key is used purely to sign part of the handshake as proof of possession. So the requirement is digitalSignature.

Why you still see keyEncipherment around: RSA certificates issued for mixed environments often carry both, so they still work with clients that negotiate TLS 1.2 with an RSA key exchange cipher suite. ECDSA certificates never needed it, because ECDSA cannot encrypt at all — it only signs.

The wider point worth making: this is a nice example of forward secrecy showing up in an unexpected place. Removing key transport is what makes past traffic un-decryptable if the server key later leaks, and the certificate's Key Usage field quietly records that architectural change.

LEAF says it was issued by:
X509v3 Authority Key Identifier:
    8A:23:EB:9E:6B:D7:F9:37:5D:F9:6D:21:39:76:9A:A1:67:DE:10:A8

INTERMEDIATE says its own identifier is:
X509v3 Subject Key Identifier:
    8A:23:EB:9E:6B:D7:F9:37:5D:F9:6D:21:39:76:9A:A1:67:DE:10:A8

And the SKI really is just a hash of the public key:
SHA1(stdin)= 8a:23:eb:9e:6b:d7:f9:37:5d:f9:6d:21:39:76:9a:a1:67:de:10:a8

What to read out of this.

• The leaf's AKI and the intermediate's SKI are the same twenty bytes. That is the link, made explicit. This is the machine-readable version of "issuer of one equals subject of the next" from Part B1 — same relationship, but keyed on the public key rather than on a name that might not be unique.
• The third command reproduces the SKI from scratch — take the public key, encode it as DER, SHA-1 it. That is the standard construction in RFC 5280, and it means the SKI is not an arbitrary label a CA invented. It is derived, so it is reproducible and collision-resistant enough for indexing.
• Yes, it is SHA-1, and no, that is not a problem. SHA-1 is broken for signatures, where an attacker wants two documents that hash the same. Here it is used purely as a lookup key, and a collision would cause a client to try the wrong certificate and then fail signature verification. It is the same nuance as using md5sum to abbreviate a modulus in Module 02 — the algorithm is weak only against the attack it is not being asked to resist.

⚠️ Where this actually bites you. During a CA key rotation, the CA has two certificates with the same Subject DN and different keys. Certificates issued before the rotation carry the old AKI; those issued after carry the new one. If your server serves the wrong intermediate, clients get unable to get local issuer certificate — verify code 20 from Exercise B2.1 — even though the file you deployed looks like the right CA. Comparing AKI to SKI is how you prove which intermediate actually belongs with your leaf.

They are an index, not a security control. The Subject Key Identifier is a hash of the certificate's own public key; the Authority Key Identifier is a copy of the issuer's SKI. Together they let a client find the correct issuer certificate quickly instead of trying every candidate.

They prove nothing on their own — an attacker can put any bytes there. The actual security comes from verifying the signature afterwards. SKI/AKI just makes finding the right key to verify with fast and unambiguous.

Why the Issuer DN is not enough: a CA routinely has several certificates sharing one Subject DN — renewals, cross-signs, key rotations. The DN is ambiguous; the key hash is not.

Where it matters operationally: after a CA key rotation, matching your leaf's AKI against your intermediate's SKI is the definitive way to confirm you deployed the right intermediate. It turns a guessing game into a one-line check.

Authority Information Access:
    OCSP - URI:http://ocsp.digicert.com
    CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalG3TLSECCSHA3842020CA1-1.crt

=== now use the CA Issuers URL to fetch the intermediate ===
fetching: http://cacerts.digicert.com/DigiCertGlobalG3TLSECCSHA3842020CA1-1.crt
fetched-issuer.der: data

subject=C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1

=== is it the same intermediate the server sent us? ===
sha256 Fingerprint=B4:9C:6E:F1:2A:73:0D:85:F9:1C:44:E8:37:B0:A2:5D:...
sha256 Fingerprint=B4:9C:6E:F1:2A:73:0D:85:F9:1C:44:E8:37:B0:A2:5D:...

What to read out of this.

• You have just done manually what Windows and macOS do automatically. That is AIA chasing, and now you know exactly what it involves: read a URL out of the certificate, download a file, and slot it into the chain.
• The downloaded file is DER, not PEM — file says data, and it has a .crt extension. Exactly the extension trap from Module 02 (Part C1). CAs publish these in DER because that is what Windows expects.
• The fingerprints match, so the fetched intermediate is byte-identical to the one the server sent. On a broken server this is how you find out which intermediate is missing: fetch it from AIA and add it to your bundle.
• Notice the URLs are http://, not https://. That is not a mistake and it is a good interview question in its own right. Fetching a certificate over HTTPS would need you to validate that connection's certificate first, which needs a chain, which is what you are trying to fetch. Plain HTTP breaks the loop, and it is safe because everything you download is signed and gets verified anyway.

🔑 The repair recipe, worth writing down, for when a server is serving an incomplete chain:

# 1. Confirm the problem
openssl s_client -connect host:443 -servername host </dev/null 2>&1 | grep 'Verify return code'
#    -> 20 (unable to get local issuer certificate)

# 2. Fetch the missing intermediate from AIA
openssl s_client -connect host:443 -servername host </dev/null 2>/dev/null \
  | openssl x509 -noout -ext authorityInfoAccess

# 3. Download, convert, append to your certificate file
curl -sS -o i.der "<CA Issuers URL>"
openssl x509 -inform DER -in i.der -out i.pem
cat server.crt i.pem > fullchain.pem

# 4. Point the server at fullchain.pem and reload

Almost certainly an incomplete chain on the server — it is sending the leaf without the intermediate.

Chrome does not fail because, on Windows and macOS, the platform fetches the missing intermediate itself using the AIA CA Issuers URL inside the certificate, or serves it from a cache of intermediates it has seen before. Java does neither. Nor do curl, OpenSSL by default, Go, Python or Node.

So the client is behaving correctly and the browser is hiding a server misconfiguration.

Confirm it in one line:

openssl s_client -connect host:443 -servername host </dev/null 2>&1 | grep 'Verify return code'

Verify code 20 — unable to get local issuer certificate — is the signature of this problem.

Fix on the server: serve fullchain.pem (leaf followed by intermediates), not just the leaf. Do not fix it by adding the intermediate to the client's trust store, which is a common and bad workaround — it hides the fault and has to be repeated on every client forever.

The lesson worth stating: "works in my browser" is not a TLS test. Browsers are the most forgiving clients there are. Test with openssl s_client or curl, which tell you the truth.

To avoid a circular dependency. Fetching over HTTPS would require validating that connection's certificate, which requires a chain and possibly a revocation check, which is exactly what you were trying to fetch. You would need a certificate to get a certificate.

It is safe because nothing is trusted on the basis of the transport. The intermediate you download is verified by signature against the chain, and a CRL or OCSP response is itself signed by the CA. HTTP is being used only as a delivery mechanism for signed data — confidentiality is not needed and authenticity comes from the signature, not the connection.

The subtlety worth adding: it also means these endpoints are cacheable by ordinary HTTP proxies and CDNs, which matters enormously at internet scale — a CRL for a large CA can be fetched millions of times an hour.

=== what did the CA actually verify? ===
X509v3 Certificate Policies:
    Policy: 2.23.140.1.2.1
      CPS: http://www.digicert.com/CPS

=== how many CT log receipts are embedded? ===
3

=== compare Subject detail: DV has almost nothing ===
subject=
    commonName                = example.com

What to read out of this.

• 2.23.140.1.2.1 is DV. The CA verified control of the domain and nothing else. No company name was checked, no legal entity, no address — and the near-empty Subject reflects that honestly.
• Three SCTs. Browsers generally want receipts from at least two independent log operators, so three is the normal issuance practice with one to spare. If a log is later distrusted, the certificate still has enough valid receipts to be accepted.
• The CPS URL points to the CA's Certification Practice Statement — the legal document describing exactly what that policy OID means in terms of checks performed. Rarely read, but it is the thing an auditor reads.
• DV is not "weak". It proves exactly what almost every use of TLS needs: that the party you are talking to controls the domain you asked for. OV and EV add legal identity, which is a different claim, and one that browsers no longer display.

They describe what the CA verified before issuing, and they are recorded as a policy OID in the Certificate Policies extension.

• DV — control of the domain only. Automated, issued in seconds, and the basis of ACME.
• OV — domain control plus verification that the organisation legally exists.
• EV — a substantially heavier legal identity check with defined procedures.

Cryptographically they are identical. The encryption, the key, the handshake — all the same. The difference is entirely in the vetting, and therefore in what the certificate asserts.

The current reality worth stating plainly: browsers stopped displaying EV distinctively around 2019, because studies showed users did not notice or act on it, and the indicator was itself being gamed. So EV's practical value today is compliance and legal identity assertion, not user-visible trust. If someone proposes buying EV certificates "for security", the honest answer is that the security is identical and the money is better spent on automation and monitoring.

Signed Certificate Timestamps — receipts from Certificate Transparency logs, proving the certificate was submitted to public, append-only, independently operated logs when it was issued.

Browsers require a sufficient number from independent operators and reject certificates without them. That requirement has applied to all publicly trusted certificates since 2018.

What it buys: detection, not prevention. CT cannot stop a CA mis-issuing a certificate for your domain. It makes it impossible for that to happen unnoticed — anyone can monitor the logs, and several CAs have been distrusted as a direct result of what CT exposed.

The operational use worth mentioning: you can monitor CT logs for your own domains and get alerted when any certificate is issued for them, including by a CA you have never used. That is a genuinely cheap and high-value control, and it also doubles as an inventory of certificates your own teams forgot to tell you about.

=== certificate fingerprint - changes at every renewal ===
sha256 Fingerprint=3F:9A:2C:8E:5B:1D:47:F0:A6:C3:9E:82:B7:4D:10:5F:C8:E3:A1:9B:6D:24:F8:70:E5:C1:A9:3B:47:D6:08:2E

=== public key fingerprint - survives renewal if the key is reused ===
d3TxKfMH8vQ2nRkL5wZaB1cYeI7uXpO0jNsGtVdFhAo=

=== prove the certificate fingerprint is just a hash of the DER file ===
SHA2-256(stdin)= 3f9a2c8e5b1d47f0a6c39e82b74d105fc8e3a19b6d24f870e5c1a93b47d6082e

What to read out of this.

• The first and third outputs are the same value, once you strip the colons and lower the case. -fingerprint is doing nothing magical — it converts the certificate to DER and hashes it. Knowing that means you can reproduce it anywhere, with any tool.
• The public key fingerprint is Base64, not hex. That is the convention for pinning — it is the format HTTP Public Key Pinning used, and the format most mobile pinning libraries and curl --pinnedpubkey expect.
• Only the public key went into the second hash. No serial, no dates, no issuer. So renew the certificate with the same key and this value is unchanged.

💡 Where you will actually use each one:

⚠️ SHA-1 fingerprints are still everywhere — in Windows dialogs, Java keytool output, and plenty of vendor documentation. For identification that is acceptable, for the same reason SKI can be SHA-1 (Exercise C4.1). But prefer SHA-256 when you have the choice, and never accept a SHA-1 fingerprint as the sole basis of a trust decision.

Pinning means the client refuses to accept anything except a specific certificate or public key, ignoring the normal trust store. It defends against exactly the thing normal PKI cannot: a legitimately issued but unauthorised certificate — a compromised or coerced CA, or a corporate inspection proxy whose root has been installed on the device.

The problems are operational and severe:

• Pin the certificate and every renewal breaks the app. With lifetimes falling to 47 days by 2029, that is unworkable. Pin the public key instead and renewal is fine as long as you reuse the key.
• Reusing the key forever is itself a risk, so you need backup pins — pin the current key and at least one pre-generated future key, so you can rotate without shipping a new client.
• A mistake is unrecoverable from the server side. If shipped pins do not match what you serve, every client is broken until they update — and for a mobile app that is an app-store cycle, days at best.

The state of play worth knowing: browsers abandoned HTTP Public Key Pinning entirely — it was removed from Chrome in 2018 — because sites bricked themselves with it, and because CT plus CAA achieves much of the same benefit without the footgun. It survives mainly in mobile apps and machine-to-machine clients, where one party controls both ends.

The judgement to show: pinning is right when you control the client and the server and the threat model genuinely includes a hostile CA. For a public website it is usually the wrong tool, and CT monitoring plus CAA records is the better answer.

What to take away from doing this once properly.

Question 5 is the one worth dwelling on. Two separate fields independently prevent a leaf certificate acting as a CA: basicConstraints: CA:FALSE and the absence of keyCertSign in Key Usage. Either one alone would be enough in a correct implementation. Both are present because in 2002 a major browser checked neither.

Question 8 is the one that will save you the most time in real work. When a deployment fails for some clients and not others, the AIA CA Issuers URL is both the diagnosis and the fix.

ch-00.pem      ISSUED BY CA CA:FALSE               CN = example.com
ch-01.pem      ISSUED BY CA CA:TRUE,pathlen:0      C = US, O = DigiCert Inc, CN = Digi
root.pem       SELF-ISSUED  CA:TRUE                C = US, O = Internet Security Resea

What to read out of this.

• Three certificates, three different roles, and you identified them from two fields. That is the whole classification: compare Subject to Issuer, then read basicConstraints.
• root.pem is SELF-ISSUED with CA:TRUE — the shape of a root. But note carefully what the script did not do: it never checked whether anything trusts it. It cannot, because that information is not in the file.
• A self-signed certificate you generate in Module 04 will produce identical output to root.pem. Same shape, same fields, same classification by this script. The only difference is that one is in /etc/ssl/certs and the other is in your home directory.

🔑 This is the point of the whole exercise, and it is worth saying in an interview: "Trust is not a property of the certificate. It is a property of the trust store." A root CA certificate is an ordinary self-signed certificate that a large number of people agreed to install. Nothing inside it makes it special.

💡 To check the other half — whether something is actually trusted — you have to ask the trust store, not the file:

openssl verify root.pem                      # is it trusted by the system store?
openssl verify -untrusted ch-01.pem ch-00.pem  # does the leaf chain to a trusted root?

One where Subject and Issuer are the same — the certificate was signed by its own private key, so it asserts its own validity with no third party involved.

Advantages: free, instant, no CA interaction, no rate limits, no public record. Fine for local development, internal test environments, and as the root of a private CA you control.

Disadvantages: nothing trusts it by default, so every client that must accept it needs manual configuration — and every client means the OS store, plus Java's cacerts, plus Node, plus Python's certifi, plus Firefox, each maintained separately (Module 02, C3). It provides encryption but no identity, so it does not defend against the man-in-the-middle attack that certificates exist to prevent.

The precision worth showing: a root CA certificate is also self-signed. The difference is not in the file — it is that browsers and operating systems shipped the root in their trust stores after an audit process. Trust lives in the store, not the certificate.

The practical advice: if you need internal certificates, do not scatter self-signed certificates across services. Run one private CA, distribute one root to your fleet, and issue leaves from it. One trust decision instead of hundreds, and revocation and rotation become possible. That is Module 05.

So the root's private key can stay offline. A root key is typically in an HSM in a safe, powered on a handful of times a year under multi-person control. A key used for every issuance cannot be protected that way.

Intermediates also make compromise survivable. If an intermediate is compromised it can be revoked and replaced, and only the certificates under it are affected. If a root is compromised there is no recovery — it cannot revoke itself, and the fix is every browser and OS vendor pushing an update to remove it, which takes years to reach everyone.

They also allow segmentation: separate intermediates per product line, per region, or per validation level, each with EKU and pathlen constraints limiting what it can do.

The detail that shows depth: this is also why pathlen:0 is standard on issuing intermediates. The root delegates once, and the intermediate is explicitly forbidden from delegating further — so a compromised intermediate can mint leaf certificates but cannot build a hierarchy underneath itself.