🔎Module 11 — Certificate Transparency, CAA & the Public Trust Ecosystem

153
71

What to read out of this — the second number is the one that should bother you.

• 153 root certificates. Your exact count will differ by distribution and by how recently the bundle was updated. Anything from roughly 130 to 180 is normal.
• 71 distinct organisations. Several organisations hold more than one root, which is why the second number is smaller.
• Every one of those 71 organisations can issue a certificate for your domain that this machine will accept without complaint. Not "could theoretically" — the software will simply say OK, exactly as it did in Module 07.

🔑 This is the correct mental model, and most people get it wrong. People imagine the trust store as a list of "companies we think are honest". It is more accurate to read it as a list of 151 spare keys to your front door, held by 71 different organisations, in about 30 different legal jurisdictions.

💡 Now imagine this at 500 hosts. It makes no difference — and that is the point. The exposure is not per-host, it is per-name. One mis-issued wildcard for your domain compromises every host you own simultaneously, and nothing on any of those 500 machines would log a thing, because from their point of view nothing happened at all.

It solves detection, not prevention. In the web PKI any trusted CA can issue a certificate for any domain, and before CT there was no reliable way for a domain owner — or a browser vendor — to learn that this had happened. Mis-issuance was discovered by accident, if at all.

CT requires every publicly-trusted certificate to be submitted to public, append-only logs before browsers will accept it. The domain owner can then watch those logs and see every certificate issued for their names, by anyone.

The detail worth adding: CT deliberately does not try to stop bad issuance, and saying so shows you understand the design. Stopping it would require the log to make a policy judgement, which would make the log a gatekeeper and a single point of failure. Instead CT makes mis-issuance undeniable and time-bounded — and that changed CA behaviour far more effectively than any technical control, because a CA that mis-issues now does so in public and faces removal from the root programs.

Nothing breaks. That is the uncomfortable answer. Chain building in Module 07 stops at the first trusted root it can reach; it has no notion of which CA should have issued. The certificate validates and the browser shows a padlock.

The attacker still needs to get traffic to their server — DNS hijack, BGP hijack, a compromised network, or a malicious proxy — but once they have that, a mis-issued certificate makes the interception invisible.

The detail worth adding: name the three layers of defence in order, because they are commonly confused. CAA reduces the chance of issuance happening at all (Part C). CT guarantees you can detect it afterwards. Revocation (Module 09) is supposed to clean up and largely does not work. A strong answer notes that the middle one — detection — is the one that actually carries the weight in practice.

HTTP Public Key Pinning (HPKP) let a site tell browsers "only accept these specific keys for me". It worked, and it was deprecated and removed — Chrome dropped it in version 72 (2019).

The reason is that it was a loaded gun pointed at the site's own foot. A pin is cached by browsers for the max-age you set. If you lose the pinned key, or your CA changes hierarchy, you have bricked your own domain for every returning visitor until the pin expires — and you cannot recall it. There was also a real hostile-pinning risk: an attacker who compromised a server briefly could set a long pin to keys they controlled, and take the site down permanently.

The detail worth adding: the useful contrast is that HPKP failed closed and CT fails open. HPKP made the site owner carry catastrophic risk to buy prevention. CT moved the burden onto the CAs and the log operators, gave the site owner detection instead of prevention, and made the failure mode "you get an email" rather than "your domain is unreachable for a year". Pinning survives today only where the failure is recoverable — inside mobile apps and internal services you also control, which is Module 12's territory.

tree size : 7
root hash : ba3c983a0449631037b48803b513f6ce56bf79515db6a5df51eb8811569046e2

inclusion proof for leaf 4 (certificate-for-host5.example):
    e8563ad760cfb8aae7bdc88d88ad15656d7f00cdbbc8726cb0e769ac61c88c75
    b70330cbdcfa869feb8cd2e9038fdd94a42dbf7ad6def471b4b639055a7a4209
    41b735fc2c87c03ce68bcfc55edc31ba5bf245b56b0997d0841e6f0f0f01ce63
verifies  : True

--- now the log operator quietly edits leaf 2 ---
new root  : bc93d0a9756065cb7ba56d4d36f2bffda18d2378cd944def1e0cb6fd61ab0a4c
same root : False

What to read out of this — three separate things, and the third is the one that matters.

• The hashes are identical on your machine. SHA-256 is deterministic and the input is fixed, so you will get byte-for-byte the same root as printed here. If you do not, you mistyped something.
• The proof for leaf 4 is three hashes, not seven. Seven leaves, log₂(7) ≈ 3. You never had to download the other six certificates to prove yours is in the log. This is why a phone can audit a log with a billion entries.
• Editing leaf 2 changed the root, even though leaf 4's proof did not mention leaf 2 at all. The change propagates upward through the shared parent nodes. A log operator who rewrites history cannot produce the old root hash again, and the old root hash is signed and already published.

🔑 This is why CT does not require you to trust the log. People assume CT works because the log operators are reputable. It works because a dishonest log gets caught by arithmetic: it must either present two different signed root hashes for the same tree size, or fail to produce a consistency proof — and in both cases it has produced cryptographic evidence of its own misbehaviour that anyone can verify forever. That evidence is called a proof of misbehaviour, and one of them ends a log.

💡 The two one-byte prefixes (0x00 for leaves, 0x01 for internal nodes) look like a detail and are not. Without them an attacker could present an internal node's hash as if it were a leaf, and prove the inclusion of a "certificate" that was never submitted. It is called a second-preimage attack on the tree, and the prefixes are the fix.

A Merkle tree is a binary tree of hashes: leaves are the hashes of the data items, every internal node is the hash of its two children, and the single hash at the top — the root — is a fingerprint of the entire dataset in a fixed 32 bytes.

CT uses it for two reasons. Efficient proofs: you can prove one certificate is in a log of a billion with about 30 hashes instead of downloading a billion certificates. Tamper-evidence: any change anywhere alters the root, and the old root has already been signed and published.

The detail worth adding: the important property is not that the log is immutable — nothing stops an operator rewriting their database. It is that rewriting is detectable by anyone, cheaply, forever. CT is built on evidence rather than prevention, and that theme runs through the whole design.

An inclusion proof answers "is this specific certificate in the log at this tree size?" — used by an auditor or a client that received an SCT and wants to confirm the promise was kept. A consistency proof answers "is the tree I see now a strict append to the tree I saw before?" — used by monitors watching a log over time to confirm nothing was removed or reordered.

Inclusion proves membership at one point in time. Consistency proves the log's history has not been rewritten between two points in time. You need both: a log could faithfully include your certificate today and quietly drop it tomorrow, and only consistency checking catches that.

The detail worth adding: the failure this pair is really guarding against is a split view — the log showing one tree to you and a different tree to the rest of the world, so a mis-issued certificate is "logged" in a version only the victim sees. Consistency proofs alone do not close that; it needs gossip, clients and monitors comparing the STHs they have seen. Gossip is the part of CT that was specified and never meaningfully deployed, and being able to name that gap is a genuinely strong signal in an interview.

=== the real certificate ===
leaf.crt: OK
=== the precertificate ===
CN = shop.ctlab.test
error 34 at 0 depth lookup: unhandled critical extension
error precert.crt: verification failed
=== how OpenSSL names it ===
            CT Precertificate Poison: critical
                NULL

What to read out of this — the two certificates are identical apart from two bytes of payload, and one of them is worthless.

• error 34 — unhandled critical extension. Add this to the verify-code table you built in Module 07. It is not a signature problem, not an expiry problem, not a name problem. The chain is perfect. The client is refusing on principle because it was told something it does not understand is essential.
• OpenSSL prints the extension by name. It knows the OID (CT Precertificate Poison) and still refuses it — because recognising an OID is not the same as being able to process it. Nothing is allowed to process this one.
• The value is NULL. Literally nothing. The extension's entire meaning is carried by its presence and its critical flag.

🔑 The counter-intuitive bit worth sitting with. Most security mechanisms fail if a client ignores them. This one fails if a client understands it. The poison extension is safe precisely because it is guaranteed to remain permanently unimplemented — the strength of the design comes from deliberate, enforced ignorance. If a browser ever shipped support for it, CT's safety model would break.

💡 What the log actually signs. The log does not sign the precertificate as you see it. It strips the poison extension and the CA's signature, and signs the resulting TBSCertificate — the certificate body. That is why the SCT you later find inside the real certificate still verifies: both documents share the same body once the poison and the SCT list are removed. Two files, one logged identity.

⚠️ If you search a public CT log for a certificate you know exists, you will often find two entries — the precertificate and the final certificate. They are not a duplicate issuance. crt.sh labels the precertificate row explicitly.

Because of a circular dependency. The SCT must be embedded in the certificate so the server can present it during the handshake with no extra configuration, but the log will not produce an SCT until it has been given the certificate — and you cannot insert anything into a certificate after signing without invalidating the signature.

A precertificate breaks the cycle. The CA signs a copy of the certificate body with a critical poison extension added, submits that to the logs, collects the SCTs, and then signs the real certificate with those SCTs embedded.

The detail worth adding: the poison extension is critical and permanently unimplemented by design — every TLS client must reject it under the RFC 5280 critical-extension rule. So the CA can safely sign a document with real authority, because the document is unusable by construction. It is a rare case where a security property is achieved by guaranteeing that nobody ever implements a feature.

Three, and only the first requires precertificates. Embedded in the certificate — the CA does it at issuance, needs no server configuration, and is how the overwhelming majority of the web works. A TLS extension (signed_certificate_timestamp) sent in the handshake. An OCSP stapled response carrying the SCTs, which Module 09 explained is now effectively dead as Let's Encrypt and others have retired OCSP.

The two non-embedded routes exist for cases where the certificate cannot be reissued but you need CT compliance, or where you want to add SCTs from newer logs to a long-lived certificate without touching the CA.

The detail worth adding: the practical consequence is that Chrome's SCT-count requirements are different for embedded and handshake-delivered SCTs, and knowing which rule applies is what separates someone who has read the policy from someone who has heard of CT. Embedded SCTs are checked against the certificate's lifetime; SCTs delivered in the handshake are simply "at least two, from two distinct operators". That is Part B.

CT Precertificate SCTs:
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : 7D:59:1E:12:E1:78:2A:7B:1C:61:67:7C:5E:FD:F8:D0:
                    87:5C:14:A0:4E:95:9E:B9:03:2F:D9:0E:8C:2E:79:B8
        Timestamp : Aug 12 12:00:00.000 2025 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256
                    12:35:63:4C:39:53:0E:AE:1F:21:F7:45:7A:28:53:C3:
                    ... 70 bytes total ...
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : EE:CD:D0:64:D5:DB:1A:CE:C5:5C:B7:9D:B4:CD:13:A2:
                    32:87:46:7C:BC:EC:DE:C3:51:48:59:46:71:1F:B5:9B
        Timestamp : Aug 12 12:00:01.000 2025 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256
                    D9:31:C2:6F:A2:B1:EB:99:9D:C5:95:6A:FA:94:CB:22:
                    ... 71 bytes total ...

What to read out of this — the signature bytes will differ on your machine (they are random); everything else will match exactly.

• This is exactly what a real public certificate looks like. Run the same sed against any certificate fetched from a public site and you will see the same block with real log IDs. Nothing about the structure is special to the lab.
• Two SCTs, two different Log ID values. That is not decoration — Part B explains why two is the floor and why they must come from two different operators.
• The log's name is nowhere in the certificate. Only the 32-byte Log ID, which is the SHA-256 of the log's public key. A client turns that into a name by looking it up in the browser's log list, which ships with the browser. No network request is involved.
• The ECDSA signature lengths differ (70 and 71 bytes). That is normal DER, not a bug — Module 06 covered why ECDSA signatures vary in length by a byte or two depending on the leading bits of r and s.

💡 Now imagine this at 500 hosts. The Log ID values become the thing you actually monitor. When a CT log is retired — and they are retired on a schedule — every certificate whose SCTs came only from that log stops counting towards Chrome's policy at renewal time. Fleets that pin, cache or air-gap their certificate pipeline discover this as a sudden wave of ERR_CERTIFICATE_TRANSPARENCY_REQUIRED on hosts nobody has touched in a year.

A Signed Certificate Timestamp is a signed promise from a CT log that it has received a certificate and will merge it into its public tree within the Maximum Merge Delay. It contains the log's ID, a timestamp, and the log's signature over the certificate body.

What it proves is narrow and worth stating precisely: it proves a log made a promise, not that the certificate is in the log. The browser verifies only the signature, using a log public key it already has.

The detail worth adding: explain why that weaker guarantee is the right design. Checking real inclusion would mean the client contacting the log, which tells the log operator every site you visit — the same privacy failure that killed OCSP. So CT deliberately settles for a non-repudiable receipt and pushes enforcement to monitors and auditors running outside the connection. Candidates who say "CT proves the certificate is public" have read a blog post; candidates who say "CT proves a log can be held responsible if it is not" have read the RFC.

By the 32-byte Log ID, which is the SHA-256 hash of the log's public key. The browser ships a log list — for Chrome, log_list.json, updated through the browser's component updater — mapping each Log ID to a public key, an operator, a state and an expiry range. The browser looks up the ID, gets the key, verifies the signature.

No network request is made at handshake time. If the Log ID is not in the list, that SCT simply does not count.

The detail worth adding: this is an operational trap, not just trivia. Log lists are versioned and go stale. A browser or an embedded TLS client with an old log list will reject SCTs from logs added since — and a client with a list newer than your certificate will not count SCTs from logs that have since been retired. Long-lived embedded devices that pin a log list are a recurring source of "it works everywhere except on the kiosks" incidents.

The MMD is the window inside which a log commits to actually merging a submitted certificate into its Merkle tree and publishing a tree head that includes it. Chrome's log policy caps it at 4 hours for RFC 6962 logs and 1 minute for static-ct-api logs.

If the log misses it, the SCT it issued is itself the evidence: anyone can present the signed SCT alongside a signed tree head from after the deadline that does not contain the certificate. That pair is a proof of misbehaviour.

The detail worth adding: the consequence is not a warning — it is removal. A log that produces a proof of misbehaviour is disqualified from Chrome's log list, and every certificate relying on it for policy compliance is affected at renewal. Because the whole ecosystem depends on logs being replaceable, Chrome's policy requires SCTs from distinct operators, so that one operator's failure never invalidates a certificate on its own.

3
3
notBefore=Jul  2 08:14:22 2026 GMT
notAfter=Sep 30 08:14:21 2026 GMT

What to read out of this — the numbers themselves are less interesting than the arithmetic you do with them.

• Your exact counts and dates will differ. Certificates are renewed constantly. What should hold is the relationship: SCT count ≥ 2, and ≥ 2 distinct log IDs.
• A 90-day certificate needs 2 SCTs; this one carries 3. The spare is deliberate insurance against a log being retired before the certificate expires.
• Distinct log IDs is not the same as distinct operators. The command above counts logs, which is the closest you can get from the certificate alone. Mapping a Log ID to its operator needs the browser's log list — which is exactly why Chrome ships one.

⚠️ If you get 0, read this before assuming something is broken. Zero SCTs on a major public site is almost always a TLS-inspecting proxy — corporate, or a security appliance — re-issuing the certificate from a local CA, exactly as described in Module 03 (B1.1). A locally-issued certificate has no reason to be in a public log, so it has no SCTs. Check the issuer:

openssl x509 -in wikipedia.pem -noout -issuer

If the issuer is your employer, your firewall vendor, or anything other than a public CA, that is your answer.

🔑 This is one of the most useful field diagnostics in the module. "Zero SCTs on a public site" is a near-definitive interception signal, and it takes one command. It is much faster than reasoning about issuers you do not recognise, because a good proxy CA looks plausible — but it can never fake SCTs, since no public log will sign for it.

It depends on the browser policy and the delivery method. For Chrome, with SCTs embedded in the certificate: two for a lifetime of 180 days or less, three for longer — and at least two of them must come from distinct log operators. For SCTs delivered through the TLS handshake or a stapled OCSP response: at least two, from distinct operators, regardless of lifetime.

The distinct-operator rule matters more than the count. Multiple logs run by one organisation collapse to a single point of failure, so they count as one witness.

The detail worth adding: explain why lifetime changes the number. An SCT is a promise whose value erodes over time, so a certificate that will be alive for two years leans on CT far harder than a 90-day one. Then connect it forward: as the industry moves to 47-day certificates under the CA/Browser Forum schedule, essentially every certificate falls into the two-SCT bucket, and CT compliance quietly gets cheaper for everyone. Candidates who tie the CT policy to the lifetime-reduction programme are showing they see the ecosystem, not just the rule.

The certificate chains to a publicly-trusted root but does not carry enough valid SCTs. curl and OpenSSL do not enforce CT policy at all, so they are perfectly happy; Chrome enforces it as a hard failure with no click-through.

Diagnose it with openssl s_client piped into openssl x509 -text and count the Signed Certificate Timestamp blocks and their distinct Log ID values.

The detail worth adding: there are three realistic causes and naming them is what makes the answer good. One — a CA issued without logging, which is a CA incident and should be reported. Two — the SCTs are all from logs that have since been retired or disqualified, which happens to long-lived certificates and is fixed by reissuing. Three, and by far the most common — something in the path is re-issuing the certificate: a middlebox, a load balancer terminating and re-originating TLS, or a CDN misconfiguration. The tell for the third is that the issuer is not a public CA.

notAfter=Sep 30 08:14:21 2026 GMT

What to read out of this — the shard is chosen by the certificate's death date, not its birth date.

• A certificate expiring 30 September 2026 must go into a shard whose range contains that date — in practice a 2026h2 shard, since most operators use half-year ranges named like Argon2026h2, Xenon2026h2, Nessie2026h2.
• Every certificate in that shard is dead by 1 January 2027. Shortly after, the shard becomes Retired and can be deleted. The whole log, permanently.
• This is why SCTs expire in usefulness. An SCT from a shard that has been retired no longer counts towards Chrome's policy. For a 90-day certificate that is irrelevant — the certificate dies long before its shard does. For an old three-year certificate it was a real problem, and it is one more reason the industry moved to short lifetimes.

💡 Now imagine this at 500 hosts. The failure mode is a golden image or a container base layer that bakes in a certificate. Nothing renews it, nothing alerts on it, and it keeps working — until the CT shard retires or the certificate expires, and then a whole fleet of hosts fails at once, on a date nobody has in a calendar. The fix is Module 10's: automate renewal, and alert on age rather than on failure.

CT logs are partitioned by the expiry date of the certificates they accept. Each shard declares a range — typically half a year, and Chrome's policy allows 3 to 12 months — and only accepts certificates whose notAfter falls inside it.

It exists to bound log size and to make logs disposable. Once every certificate a shard could hold has expired, the shard has no security value and can be retired and deleted.

The detail worth adding: the operational consequence is that SCTs have a shelf life. When a shard retires, SCTs from it stop counting towards CT policy. For 90-day certificates this never bites; for long-lived certificates in embedded devices and appliances it absolutely does, and it produces failures with no obvious trigger, on hosts nobody touched.

The move to static-ct-api logs — logs served as immutable static tiles from object storage instead of a database behind an API. Sunlight is the best-known implementation. It makes logs dramatically cheaper to run and to mirror, and Chrome's policy reflects that: a 1-minute maximum merge delay for static logs versus 4 hours for RFC 6962 ones.

Chrome has also removed its requirement that at least one SCT come from a classic RFC 6962 log — enforcement ended on 15 April 2026, with Chrome 144 the first release to drop it. Certificates can now be fully compliant with SCTs from static logs alone.

The detail worth adding: the part that affects a team directly is monitoring. Any CT tooling written against the RFC 6962 get-entries endpoint is blind to tile-based logs, so a monitoring setup built before 2025 may quietly be watching a shrinking fraction of issuance. Saying "we should re-verify that our CT monitor covers the static logs" is the answer of someone who has actually operated this.

This one comes from a live public service, so your output will not match line for line — the numbers move every day. What matters is the shape:

214 entries
2026-08-14  C=US, O=Let's Encrypt, CN=E7                 *.wikipedia.org
2026-08-14  C=US, O=Let's Encrypt, CN=E7                 *.wikipedia.org
2026-08-02  C=US, O=Let's Encrypt, CN=E5                 *.m.wikipedia.org
...
41 distinct names
  *.m.wikipedia.org
  *.wikipedia.org
  *.zero.wikipedia.org
  wikipedia.org

What to read out of this — four things, and the last one is why security teams love this endpoint.

• Entries come in pairs. Remember Part A: the precertificate and the final certificate are both logged. crt.sh returns both, which is why the entry count is roughly twice the certificate count.
• The issuer tells you the CA and the intermediate. CN=E7 is a specific Let's Encrypt intermediate. If a name you own suddenly shows an issuer you have never used, that is the alarm.
• %25 is a URL-encoded %, which is SQL's wildcard. crt.sh is a PostgreSQL database behind a web form; %.wikipedia.org means "any subdomain".
• You never proved you own the domain. You cannot — and neither can anyone else. CT is public by design, and that cuts both ways, which is C2.

⚠️ crt.sh rate-limits and sometimes times out. It is a free service run by Sectigo as a public good. Do not build production monitoring on top of it — use it for investigation and run a real monitor for alerting.

🔑 Do this for your own domain right now. Substitute your employer's domain, or your own. Nearly everyone who runs this for the first time finds at least one certificate they had forgotten about, and a surprising number find a name that should not exist.

Monitor the CT logs. Every publicly-trusted certificate must be logged before browsers accept it, so the logs are a complete record of issuance for your names, by any CA. In practice: a hosted monitor such as Cert Spotter or Censys for alerting, crt.sh for ad-hoc investigation, or self-hosted certspotter if you would rather not hand your watch list to a third party.

Configure it as an alert, not a dashboard — a certificate appearing from a CA you do not use should page someone.

The detail worth adding: say what a good alert looks like, because "monitor CT" is the easy half. Alert on issuer not in your allow-list and on names that do not match your inventory, not on every issuance — otherwise ACME renewals bury the signal within a week. And pair it with CAA: CAA makes unexpected issuance unlikely, CT makes it visible, and the two together give you a control that both narrows the attack and detects it when it happens anyway.

First establish whether it is really unauthorised. Most such alerts are internal: another team, a CDN or hosting provider issuing on your behalf, a marketing platform, or a forgotten ACME client. Check the issuer, the SANs, the validity dates and the ACME account if you can identify it.

If it is genuinely unauthorised, it means the attacker completed domain validation, so treat it as a domain-control compromise until proven otherwise: check DNS records and registrar audit logs, check web-root access if HTTP-01 could have been used, and check for a BGP or resolver-level hijack. Report it to the issuing CA — they are obliged to investigate and revoke — and to the browser root programs if the CA is unresponsive.

The detail worth adding: the ordering that shows operational judgement is that revocation is the last and least useful step (Module 09 — soft-fail means revocation may reach nobody). The valuable actions are closing the validation path the attacker used, adding or tightening CAA including accounturi pinning, and preserving evidence. And there is a hard truth worth voicing: a mis-issued certificate is a symptom. Something else was already broken for it to exist.

Live data again, so your list will differ. The shape is what matters:

612 names, 37 that look non-public
   admin.mozilla.org
   bugzilla-dev.allizom.org
   ci-staging.mozilla.org
   git-internal.mozilla.org
   stage.mozilla.org
   ...

What to read out of this — you just did external reconnaissance on a large organisation, in one command, with no tools and no permission needed.

• Every one of those names came from a certificate somebody requested on purpose. None of it is a leak in the usual sense. It is the system working exactly as designed.
• The keyword filter is crude and still works. A real attacker uses a much longer word list and cross-references issuance dates to spot new infrastructure within hours of it appearing.
• Some of those hosts may not resolve in public DNS. That is the uncomfortable part: CT reveals names that DNS enumeration never would.

🔑 The lesson is not "CT is dangerous". It is that hostname secrecy has not been a viable control since 2018, and any design that relies on an internal service being hard to find is relying on something that a public log gives away for free. Put internal services behind a private CA and real authentication — which is Module 12.

💡 Now imagine this at 500 hosts. This is the moment to grep your own CT history for names you thought were private, and to add a review step to certificate requests. A single certificate with 200 SANs, issued once by a well-meaning engineer to save time, publishes the complete internal topology of a company forever.

It publishes every hostname you ever put on a publicly-trusted certificate, permanently and searchably. That includes staging, admin, CI, VPN and internal service names — a complete map of an organisation's estate, available to anyone with one HTTP request to crt.sh. It is now a standard first step in reconnaissance.

There is no way to remove an entry. The log is append-only by design, so a name submitted once is public forever.

The detail worth adding: the right conclusion is not that CT is a bad trade — it plainly is not — but that it closed off hostname obscurity as a control, and some organisations had been quietly relying on it. The mitigations are wildcards for internal names, a private CA for anything not public, and treating the SAN list as a permanent disclosure decision. A candidate who names the wildcard trade-off — fewer names logged, but a much bigger blast radius on one key — is thinking about it properly rather than reciting.

--- DV
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
--- OV
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.2
--- EV
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.1
subject=CN = wikipedia.org
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1

What to read out of this — the last four lines are the real exercise.

• The Subject is just CN = wikipedia.org. No O=, no L=, no C=. That is a DV certificate, and the policy OID confirms it.
• One of the largest sites in the world runs on a free DV certificate. So do most of the others. That is the honest state of the industry, and it is a useful thing to say out loud in an interview when someone implies OV or EV is a security requirement.
• The lab certificates prove OpenSSL reads the OID and nothing more. Nothing validated anything — I simply asserted the OID. Policy OIDs are meaningful only because the CA is audited against them; they carry no self-enforcing power.

⚠️ If your wikipedia.pem shows a corporate issuer and no policy OID at all, you are behind a TLS-inspecting proxy again (B1.1). Re-run the check on a network you control if you want the real answer.

Only what the CA checked before issuing. DV verifies domain control alone and is fully automatable — the ACME challenges are exactly this. OV additionally verifies that a named organisation legally exists and is entitled to the domain, so the Subject carries a checked O=. EV applies the CA/B Forum's Extended Validation Guidelines: incorporation records, operational existence, physical address, and the requester's authority.

The cryptography and the TLS handshake are identical across all three. You can tell them apart by the certificate policy OID: 2.23.140.1.2.1, 2.23.140.1.2.2 and 2.23.140.1.1.

The detail worth adding: the honest commercial answer is that EV's value collapsed when Chrome 77 and Firefox 70 removed the green identity bar in 2019, after research showed users neither noticed nor acted on it. What survives is niche and real — some regulated sectors and some insurance or procurement requirements still specify OV or EV — but presenting it as a security control for the TLS connection is wrong, and interviewers notice.

The encryption is identical. A Let's Encrypt DV certificate and a several-hundred-pound EV certificate use the same key algorithms, negotiate the same TLS 1.3 handshake and offer exactly the same protection against interception. The difference is a paperwork check the CA performed once, before issuing.

If anything the free certificate has an operational security advantage: it is short-lived and issued through automation, so it rotates constantly and a compromised key has a short window of use. Long-lived manually-installed certificates are the ones that go stale, get copied between hosts and quietly outlive the person who installed them.

The detail worth adding: redirect the conversation to where the real risk is. Ask what the actual threat is. If it is mis-issuance, the answer is CAA plus CT monitoring, which costs nothing. If it is compliance, get the requirement in writing and buy exactly what it says. If it is "it feels safer", show them that the site they most trust is running on DV. Being able to redirect a request toward the control that actually addresses the risk is the point of the question, not the certificate.

=== who holds the most roots here?
      8 DigiCert Inc
      6 SSL Corporation
      5 QuoVadis Limited
      4 Google Trust Services LLC
      4 GlobalSign
      4 Amazon
      4 "Entrust
      3 GlobalSign nv-sa
=== CAs from the distrust table in C4 ===
subject=O = Entrust.net, ... CN = Entrust.net Certification Authority (2048)
subject=C = US, O = "Entrust, Inc.", ... CN = Entrust Root Certification Authority
subject=C = US, O = "Entrust, Inc.", ... CN = Entrust Root Certification Authority - EC1
subject=C = US, O = "Entrust, Inc.", ... CN = Entrust Root Certification Authority - G2
subject=C = US, O = "Entrust, Inc.", ... CN = Entrust Root Certification Authority - G4

What to read out of this — two findings, and the second one is the whole lesson of C4.

• Symantec, Thawte, GeoTrust and VeriSign are gone. Distrusted in 2018, and by now removed from the bundle entirely. Their absence is what a completed distrust looks like.
• Five Entrust roots are still here, in an up-to-date trust store, even though Chrome stopped trusting Entrust TLS certificates with notBefore after 31 October 2024. Your exact list will vary by distribution and bundle version.
• Several organisations hold four to eight roots each. Old roots are kept alive for years because devices and pinned clients still chain to them.

🔑 This is the C4 lesson made concrete: your OS trust store is not the browser's decision. Chrome ships its own root store and applies its own constraints on top — including date-based distrust that no OS bundle expresses. A root being present in ca-certificates.crt tells you openssl and curl will accept it. It tells you nothing about what Chrome will do.

💡 Now imagine this at 500 hosts. This is why "we tested with curl and it was fine" is not a deployment check. Distrust decisions are made per root program, on dates, and only the browser enforces them. Module 13's fleet auditing has to compare against the browser's view, not the host's.

Root program operators — Google (Chrome Root Program), Mozilla, Apple and Microsoft. Each publishes a policy requiring annual audits with unbroken coverage, compliance with the CA/Browser Forum Baseline Requirements, full disclosure of intermediates, and public incident reporting. They coordinate disclosure through the CCADB.

Removal is usually gradual rather than instant: a distrust date is announced, certificates issued after that date stop being trusted, and existing ones are allowed to expire. That avoids breaking the web on a single day.

The detail worth adding: the case that shows you understand the mechanism is Entrust, distrusted by Chrome for certificates with notBefore after 31 October 2024. Google's stated reasoning was not one catastrophic mis-issuance but a pattern of compliance incidents and unsatisfactory responses. Compare that with DigiNotar, removed in days because it was actively compromised. The two shapes — graceful notBefore distrust versus emergency removal — are the two tools root programs have, and knowing when each is used is the substance of the question.

In 2011 the Dutch CA DigiNotar was breached and the attacker issued fraudulent certificates, including one for *.google.com that was used to intercept the traffic of roughly 300,000 users in Iran. The certificate had been in use for weeks. It was discovered because a Chrome user in Iran hit a certificate-pinning error and posted about it in a forum.

It matters because of how it was found: by coincidence. There was no systematic way for Google, or anyone, to learn that a certificate for their domain existed.

The detail worth adding: DigiNotar is the direct cause of Certificate Transparency — Google began the CT work in its aftermath. The second lesson is about blast radius: DigiNotar also issued certificates for the Dutch government's PKIoverheid, so removing it from trust stores broke real government services, and browser vendors had to weigh that against leaving a compromised CA trusted. That tension — removing a CA hurts its legitimate users — is exactly why distrust is normally phased by notBefore date rather than done in one step.

=== a locked-down single-CA policy
0 issue "pki.goog"

=== a multi-CA policy with a reporting address
wikipedia.org.		600	IN	CAA	0 issue "letsencrypt.org"
wikipedia.org.		600	IN	CAA	0 issue "pki.goog"
wikipedia.org.		600	IN	CAA	0 iodef "mailto:[email protected]"

=== a domain with no CAA at all
[nothing above means any CA may issue]

What to read out of this — three different postures, and the third is the default everybody has.

• google.com allows exactly one CA, their own. Tight, deliberate, and only workable if you never need a second issuer in a hurry.
• wikipedia.org allows two CAs and publishes an iodef address. That is the shape most organisations should copy: a primary CA, a fallback, and a mailbox that gets told when someone else tries.
• example.com has no CAA record. So does the overwhelming majority of the internet. Every one of the 71 organisations from Exercise A1.1 may issue for it, and none of them will pause to think about it.
• The order of records will vary between queries. DNS does not preserve record order and resolvers commonly rotate them. Never write a script that depends on the first line.

🔑 The asymmetry worth noticing. Publishing CAA costs you one DNS record and nothing else — no software, no renewal, no maintenance. Not publishing it leaves the door open to 71 organisations. There are very few controls in security with that ratio, which is why "does the domain have CAA?" is a reasonable one-line audit question for any estate.

💡 Now imagine this at 500 hosts. CAA is per-domain, not per-host, so 500 hosts under one domain are covered by one record. That makes it one of the very few security controls whose cost does not scale with your fleet — and one of the strongest arguments for doing it today rather than after the next incident.

no CAA at:    api.internal.wikipedia.org
no CAA at:    internal.wikipedia.org
CAA found at: wikipedia.org
   0 iodef "mailto:[email protected]"
   0 issue "letsencrypt.org"
   0 issue "pki.goog"

no CAA at:    www.example.com
no CAA at:    example.com
no CAA anywhere up the tree — any CA may issue

What to read out of this — the first block is the answer to "why did my certificate request fail when dig showed nothing?"

• Three queries, not one. A CA asking about api.internal.wikipedia.org does exactly this walk. Two of the three lookups return nothing, and that is normal — the answer lives at the apex.
• The script stops before the TLD ([ "$name" = "${name#*.}" ] && break). RFC 8659's algorithm technically climbs to the root, but CAA records on public suffixes are not a thing you will meet in practice.
• The second case is the internet's default. No CAA at any level, so any of the 71 organisations may issue. Fix that for your own domains before you finish this module.

🔑 Keep this script. "Which CAA policy actually applies to this hostname?" is a question you will be asked in the middle of a failed issuance, under time pressure, and answering it with a single dig is how people get it wrong. Part E folds this into the module's capstone tool.

💡 A subtle failure this catches: a wildcard request for *.shop.example.com is evaluated against the CAA of shop.example.com, not of example.com — the wildcard label is stripped first, then the climb begins. If shop.example.com has its own restrictive record, the wildcard fails while ordinary certificates under the apex keep working.

A DNS record listing which CAs may issue certificates for a domain, using the tags issue, issuewild and iodef. Since September 2017 the CA/Browser Forum Baseline Requirements have required every publicly-trusted CA to check CAA before issuing and to refuse if it is not authorised.

It does not stop anyone technically — it is not enforced by cryptography or by the client. It works because CAs are contractually and audit-bound to honour it, and ignoring it is a reportable incident that root programs act on.

The detail worth adding: set expectations correctly, because that is the real question. CAA does not protect you from a compromised or malicious CA, which can simply ignore it — but ignoring it produces a durable, auditable violation, and CT (Part A) makes the resulting certificate visible. So the honest framing is that CAA raises the cost and CT provides the evidence, and neither is a technical prevention. The pairing is the point.

It queries CAA at api.shop.example.com, then shop.example.com, then example.com, climbing towards the root, and stops at the first name that has any CAA record set. There is no inheritance and no merging — the first record set found is the complete policy. If nothing is found anywhere, CAA does not restrict issuance.

CNAMEs are followed by DNS in the normal way, so querying a CNAME gives you the target's CAA.

The detail worth adding: the operational trap is that a CAA record on a subdomain silently replaces the parent's, so an over-helpful record at shop.example.com can lock out the CA that the rest of the estate uses. The second trap is that a single dig at one label tells you nothing — you have to climb, which most people do not, which is why "we don't have CAA" and "our CAA blocked issuance" are frequently said about the same domain in the same incident.

0 issue ";" — an empty issuer-domain-name, which forbids all issuance. Add 0 issuewild ";" alongside it to be explicit about wildcards, and an iodef address so you are told when someone tries.

It is the right record for parked domains, defensive brand registrations, and internal-only zones that should only ever be served by a private CA.

The detail worth adding: this is the highest-value CAA record most organisations never set, because the domains it applies to are precisely the ones nobody owns operationally. A forgotten brand-protection domain with no CAA, no monitoring and stale DNS delegation is a far easier target than the flagship site everyone watches — and the certificate an attacker gets for it is fully valid.

{"body": {"key": {"kty": "RSA", "n": "sX9...", "e": "AQAB"}, "contact":
["mailto:[email protected]"], "status": "valid"}, "uri":
"https://acme-v02.api.letsencrypt.org/acme/acct/1234567", "new_authzr_uri":
null, "terms_of_service": null}

What to read out of this — the uri field is the value you pin, and it is the only part that matters.

• regr.json is certbot's record of the registration. The uri is exactly what accounturi expects, copied verbatim including the scheme.
• The key in that file is your account key, not any certificate key — Module 10 (B2) drew that distinction and this is where it becomes concrete. The account URI is a name for that key. Lose the key and you lose the account and, if you have pinned it, your ability to renew.
• If the find returned nothing, you have not run certbot on this machine, which is fine — the second block still shows you the record shape.
• All three records go together. issue alone leaves wildcards governed by nothing stricter; the issuewild line pins them the same way; iodef is how you learn that someone tried.

🔑 The order to adopt these in, if you are starting from nothing. First publish plain issue for the CAs you actually use — that alone takes you from 71 organisations to one or two, and cannot break anything you are not already doing. Then add iodef. Then, once renewals have run cleanly for a cycle, add validationmethods. Add accounturi last, because it is the one that will lock you out if your ACME account is ever rebuilt.

💡 Now imagine this at 500 hosts. Because CAA is per-domain, adding validationmethods=dns-01 protects all 500 in one change. But it also requires all 500 to renew via DNS-01, so do the reverse check first: find every host still using HTTP-01 and migrate it, or your next renewal wave fails silently at 3am.

Naming one CA takes you from about seventy organisations down to one, which is the big win — but that one CA issues to millions of accounts, and it will issue to anyone who passes its validation for your domain. So the remaining exposure is an attacker who can complete a challenge: web-root or port-80 access for HTTP-01, port 443 for TLS-ALPN-01, or DNS control for DNS-01.

RFC 8657 adds two parameters. accounturi restricts issuance to one specific ACME account. validationmethods restricts which challenge types are acceptable.

The detail worth adding: validationmethods=dns-01 is the one to reach for first, and the reasoning is what makes the answer good — it collapses every issuance path down to your DNS zone, which is usually your smallest and best-guarded surface and often not internet-facing at all. One DNS record removes web-server compromise as a route to a valid certificate for your domain. accounturi is stronger still but is the classic self-inflicted outage, because rebuilding an ACME account changes the URI and instantly blocks your own renewals.

1.1.1.1          0 issue "letsencrypt.org" 0 issue "pki.goog" 0 iodef "mailto
8.8.8.8          0 iodef "mailto:[email protected]" 0 issue "pki.goog" 
9.9.9.9          0 issue "pki.goog" 0 iodef "mailto:[email protected]" 
208.67.222.222   0 issue "letsencrypt.org" 0 iodef "mailto:dns-admin@wikimedi

What to read out of this — the set is the same everywhere; only the order differs.

• Different order, same records. Resolvers rotate record order, which is why the truncated lines look different. That is not disagreement.
• This is a poor man's MPIC and it still catches real problems. Four public resolvers are four vantage points. If one of them returned nothing, or returned a different issue value, you would have found a genuine inconsistency before your CA did.
• It is not a substitute for the real thing. All four of these resolvers are large anycast networks that may still reach your nameservers over similar paths. A real MPIC implementation queries from separate networks in separate registries.

🔑 Add this to your pre-flight checklist before any CAA change. Publish the record, wait for the TTL, then run this loop. A CAA record that has propagated to your provider's primary but not to a secondary nameserver will pass your own dig and fail the CA's quorum — and the error you get back will not say so.

💡 Now imagine this at 500 hosts. MPIC turns "our DNS is a bit flaky in one region" from an annoyance into a hard stop on certificate issuance across the whole estate. Under 47-day certificate lifetimes (Module 10), a DNS inconsistency that blocks issuance for a fortnight is an outage, not a ticket. DNS reliability is now a TLS availability dependency, and that is a genuinely new thing to put in a runbook.

Multi-Perspective Issuance Corroboration: a CA must perform domain control validation and CAA lookups from several network vantage points and corroborate the answers before issuing. It became mandatory under the Baseline Requirements on 15 March 2025 and the required number of perspectives has been increasing — at least four remote perspectives since 15 June 2026, rising to five in December 2026.

It addresses BGP hijacking and path-dependent DNS manipulation. An attacker who can make the CA's traffic reach their server, rather than yours, can complete HTTP-01 validation and obtain a fully valid certificate for a domain they do not own. Hijacking a route so that it is seen from every perspective simultaneously is far harder than from one.

The detail worth adding: the part people miss is that MPIC covers CAA lookups too, not just the challenge. A hijack that only spoofed the challenge but left CAA intact would still be caught by your CAA record — so an attacker had to spoof both, and MPIC now makes both harder from one vantage point. And note the operational consequence: your nameservers must answer consistently from everywhere, which turns geo-restricted or split-horizon DNS into an issuance failure.

Assume the CA is seeing something you are not. Check the CAA record from several resolvers on different networks and from different regions, and check every authoritative nameserver for the zone individually rather than trusting the resolver's answer — a secondary that has not picked up a zone transfer will serve stale or missing CAA to a fraction of queries.

Then check DNSSEC. Since 15 March 2026 CAs must DNSSEC-validate CAA lookups, and a SERVFAIL from a broken or expired DNSSEC signature is explicitly not permission to issue. An expired zone signature produces exactly this symptom: intermittent, resolver-dependent, invisible from a cached local view.

The detail worth adding: the framing that lands is that MPIC made DNS availability a TLS availability dependency. It used to be that a flaky secondary nameserver degraded resolution slightly; now it can block issuance entirely, and with 47-day certificate lifetimes there is much less slack before that becomes an outage. Say that you would add multi-region DNS checks to monitoring rather than only fixing the immediate record.

#!/usr/bin/env bash
# ct-caa-audit — for one host: is its certificate CT-logged, and is issuance locked down?
host="$1"; port="${2:-443}"
[ -z "$host" ] && { echo "usage: $0 <host> [port]"; exit 2; }

# portable "seconds since epoch" for an OpenSSL date, GNU and BSD/macOS
epoch() { date -d "$1" +%s 2>/dev/null || date -j -f "%b %e %T %Y %Z" "$1" +%s; }

# ---------- 1. fetch ----------
crt=$(mktemp)
echo | openssl s_client -connect "$host:$port" -servername "$host" 2>/dev/null \
     | openssl x509 -out "$crt" 2>/dev/null
[ -s "$crt" ] || { echo "$host: could not fetch a certificate"; rm -f "$crt"; exit 1; }

echo "=== $host:$port ==="
openssl x509 -in "$crt" -noout -subject -issuer | sed 's/^/  /'

# ---------- 2. Certificate Transparency ----------
n=$(openssl x509 -in "$crt" -noout -text | grep -c "Signed Certificate Timestamp")
logs=$(openssl x509 -in "$crt" -noout -text | grep -A1 "Log ID" \
       | grep -v '^--' | paste - - | sort -u | wc -l)
nb=$(openssl x509 -in "$crt" -noout -startdate | cut -d= -f2)
na=$(openssl x509 -in "$crt" -noout -enddate   | cut -d= -f2)
days=$(( ( $(epoch "$na") - $(epoch "$nb") ) / 86400 ))
need=2; [ "$days" -gt 180 ] && need=3
printf "  CT      : %d SCTs from %d logs; lifetime %dd -> Chrome needs %d\n" \
       "$n" "$logs" "$days" "$need"
if   [ "$n" -eq 0 ];       then echo "            !! zero SCTs on a public host - suspect TLS interception"
elif [ "$n" -lt "$need" ]; then echo "            !! below Chrome's CT policy"
else                            echo "            ok"
fi

# ---------- 3. CAA, climbing the tree the way a CA does ----------
name="$host"; rec=""; at=""
while [ -n "$name" ]; do
  rec=$(dig +short CAA "$name"); [ -n "$rec" ] && { at="$name"; break; }
  name="${name#*.}"; [ "$name" = "${name#*.}" ] && break
done
if [ -z "$at" ]; then
  echo "  CAA     : none up the tree -- ANY public CA may issue for $host"
else
  echo "  CAA     : set at $at"
  echo "$rec" | sed 's/^/            /'
  echo "$rec" | grep -q iodef             || echo "            .. no iodef: nobody is told when a CA refuses"
  echo "$rec" | grep -q issuewild         || echo "            .. no issuewild: wildcards follow the issue rules"
  echo "$rec" | grep -q accounturi        || echo "            .. no accounturi: any account at that CA may issue"
  echo "$rec" | grep -q validationmethods || echo "            .. no validationmethods: any challenge type is allowed"
fi
rm -f "$crt"

Run it against three domains with deliberately different postures:

chmod +x ~/tls-lab/m11/ct-caa-audit.sh
~/tls-lab/m11/ct-caa-audit.sh google.com
~/tls-lab/m11/ct-caa-audit.sh example.com

=== google.com:443 ===
  subject=CN = google.com
  issuer=C = US, O = Google Trust Services, CN = WR2
  CT      : 3 SCTs from 3 logs; lifetime 90d -> Chrome needs 2
            ok
  CAA     : set at google.com
            0 issue "pki.goog"
            .. no iodef: nobody is told when a CA refuses
            .. no issuewild: wildcards follow the issue rules
            .. no accounturi: any account at that CA may issue
            .. no validationmethods: any challenge type is allowed

=== example.com:443 ===
  subject=CN = example.com
  issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
  CT      : 3 SCTs from 3 logs; lifetime 365d -> Chrome needs 3
            ok
  CAA     : none up the tree -- ANY public CA may issue for example.com

1. The lifetime arithmetic is the part that earns its place. example.com at 365 days needs three SCTs and has exactly three. google.com at 90 days needs two and carries three. Neither number is interesting on its own — the comparison is.

2. Reporting what is missing is the design decision that makes this tool useful. A tool that prints the CAA records you have tells you what you already know. A tool that prints the four protections you have not configured turns a status check into a work list, and it is what makes the difference between an audit script and a dashboard nobody reads.

3. If you get 0 SCTs on every host, you are behind a TLS-inspecting proxy — the certificate you are reading was re-issued locally and was never in any public log. The script says so deliberately rather than reporting a policy violation, because that misdiagnosis wastes real time. Re-run it from a network you control.

4. epoch() exists because of macOS. BSD date has no -d, so the GNU form fails and the || falls through to the BSD form. Every portable TLS script you write will end up with a function like this, and it is worth having once rather than five times.

What is still missing, honestly: this checks one host at a time and does not verify SCT signatures — it counts blocks of text. Verifying an SCT means fetching the log list, matching the log ID to a public key and checking an ECDSA signature over the reconstructed precertificate, which is a real piece of software rather than twenty lines of shell. It also does not map log IDs to operators, so it cannot check the distinct-operator rule. Both gaps are honest ones to state out loud: the script tells you where to look, not that everything is provably correct.

🔑 Keep this file. Module 13 merges certinfo, tlsinfo, tlsdiag, tlsdeploy-check, crl-health, acme-health and ct-caa-audit into one auditing tool you can point at a whole estate.

CT Precertificate SCTs: 
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : 7D:59:1E:12:E1:78:2A:7B:1C:61:67:7C:5E:FD:F8:D0:
                    87:5C:14:A0:4E:95:9E:B9:03:2F:D9:0E:8C:2E:79:B8
        Timestamp : Aug 12 12:00:00.000 2025 GMT
CT Precertificate Poison: critical
    NULL
X509v3 Certificate Policies: 
    Policy: 2.23.140.1.1

What to read out of this — three commands replaced three fragile grep -A pipelines.

• -ext takes the extension's short name, and OpenSSL knows the CT ones by name: ct_precert_scts and ct_precert_poison. No OID, no line-counting, no -A20 guessing at how many lines to keep.
• It also takes an OID directly if the extension has no short name, which is how you read a proprietary extension a vendor has invented.
• The output is unindented, unlike -text, which makes it much easier to feed into a script.

🔑 This is a general habit, not a CT trick. Anywhere you were about to write openssl x509 -text | grep -A5 "Something", check whether -ext knows the name first. It is more precise, it does not break when the number of output lines changes, and it makes the intent of the command obvious to whoever reads it next.

Because web PKI trust is a union, not an intersection. A certificate is accepted if it chains to any root in the trust store, and there is no field in X.509 that restricts a domain to a particular CA. A typical trust store holds around 150 roots belonging to roughly 70 organisations.

Every one of those organisations can issue for your name, and every browser will accept it. That is the problem CT and CAA exist to manage — neither of them removes it.

That a CT log signed a promise to publish the certificate within its maximum merge delay. Nothing more. The browser verifies only the signature, against a log public key it already ships.

It does not prove the certificate is in the log. Checking that would require the browser to contact the log, which would leak browsing history — the same privacy failure that killed OCSP. Enforcement is pushed to monitors and auditors outside the connection path.

Because a precertificate is signed by a real CA with real authority, so it must be impossible to use. RFC 5280 requires clients to reject any certificate containing a critical extension they do not understand, and no client understands the poison OID 1.3.6.1.4.1.11129.2.4.3.

A non-critical extension would simply be ignored, and the precertificate would be a fully usable certificate that the CA had signed and never intended to be trusted. The safety comes from the extension being permanently unimplemented by design.

Embedded SCTs: 2 at 180 days or less, 3 above that. So a 90-day certificate needs two, and a two-year certificate needs three — though two-year public certificates no longer exist under the current lifetime limits. At least two must come from distinct log operators, not just distinct logs.

SCTs delivered through the TLS handshake or a stapled OCSP response need at least two from distinct operators regardless of lifetime.

CT logs are partitioned by the expiry date of the certificates they accept, in ranges of 3 to 12 months, so that a shard can be deleted once everything in it has expired.

When a shard is retired, SCTs from it stop counting towards CT policy. A long-lived certificate whose SCTs all came from a now-retired shard can start failing in Chrome with no configuration change and no expiry — a failure with no obvious trigger, on hosts nobody has touched.

A TLS-inspecting proxy — corporate, MDM or a security appliance — has terminated the connection and re-issued the certificate from a locally-trusted CA. A locally-issued certificate has no reason to be in a public log, so it carries no SCTs.

Confirm by checking the issuer. This is one of the fastest interception tests available: a good proxy CA can look plausible, but it can never fake SCTs, because no public log will sign for it.

Every hostname on a publicly-trusted certificate is published permanently and searchably, so staging, admin, CI and VPN names become public reconnaissance material. There is no takedown — the log is append-only.

Mitigate by using wildcards for internal names (accepting the larger blast radius on one key), putting internal services on a private CA so nothing is logged at all, and treating the SAN list as a permanent disclosure decision made before the request. And accept that hostname obscurity has not been a control since CT enforcement began.

Only what the CA verified before issuing: domain control (DV), plus verified organisation existence (OV), plus the full EV Guidelines checks on incorporation, address and requester authority (EV). The policy OIDs are 2.23.140.1.2.1, 2.23.140.1.2.2 and 2.23.140.1.1.

It has no effect at all on the TLS connection — same algorithms, same handshake, same strength. The browser identity UI for EV was removed by Chrome 77 and Firefox 70 in 2019, which removed most of its commercial rationale.

It queries CAA at the exact name, then climbs towards the root one label at a time, and stops at the first name with any CAA record set. There is no inheritance and no merging.

The classic mistake is assuming a subdomain record adds to the parent's. It replaces it entirely — so a well-meaning record on shop.example.com can lock out the CA the rest of the estate uses. The second mistake is running one dig at one label, seeing nothing, and concluding there is no policy.

accounturi restricts issuance to one specific ACME account at that CA, identified by its account URL. validationmethods restricts which challenge types may be used — http-01, dns-01, tls-alpn-01.

validationmethods=dns-01 is the higher-value one for most estates: it makes DNS control the only path to a certificate, removing web-root and port-80 compromise as an issuance route. accounturi is the strongest pin and the easiest way to lock yourself out, because rebuilding the ACME account changes the URI.

Multi-Perspective Issuance Corroboration: CAs must perform domain validation and CAA lookups from several network perspectives and corroborate the results, to defeat BGP hijacking and path-dependent DNS manipulation. Mandatory since 15 March 2025; at least four remote perspectives since 15 June 2026, rising to five in December 2026, with one non-corroboration tolerated up to five perspectives.

It requires your nameservers to answer consistently from everywhere. Geo-restricted, firewalled or split-horizon DNS now causes intermittent issuance failures that look fine from your own dig. Since March 2026 CAA lookups must also be DNSSEC-validated, so an expired zone signature blocks renewal.

Not usually a single mis-issuance. In most of the major cases — Symantec, WoSign/StartCom, Entrust — the fatal problem was the pattern of behaviour afterwards: slow disclosure, incomplete root-cause analysis, defensive responses, undisclosed ownership or relationships.

Removal is normally phased by notBefore date so existing certificates expire naturally, because distrusting a CA also breaks its legitimate customers. Emergency removal, as with DigiNotar in 2011, happens only when the CA is actively compromised.