There is a fifth, incredibly common, (arguably) non-malicious possibility.
You don't control the entirety of your web stack, and your hosting provider, or DNS provider, or someone else, has decided to be 'helpful' (either blindly, or due to some misconfiguration somewhere along the line) and issue a certificate on your behalf, as they are able to intercept CA validation traffic at the DNS, TLS, or HTTP layer.
Or indeed you're in a position of overlapping authority.
Universities will often have a cash-strapped organisation-wide IT Department (e-mail for english majors) and another layer of IT in certain academic departments (computer labs for CS students) and another layer of IT after that (the centre for machine learning paid for that cluster, of course they have full authority over it) - and often it's that third-level body that's getting all the grant funding and publishing all the papers.
The people who control www.example.edu might basically be the marketing department for their glossy student recruitment brochure. Who's to say they have authority over certificate issuance for datasets.ml.cs.example.edu ?
This is also arguably malicious, it is not for them to get certificates for your domain and snoop your traffic. I’d hope this is not ‘incredibly common’, in my opinion it is completely unacceptable.
The certificate certifies the holder is the owner of the domain, if some third party gets a certificate that’s fraudulent. In at least some jurisdictions making a fraudulent claim like that is illegal.
CAs don't have to report their certificates to CT logs, and actually there is no reporting in a variety of use cases. However, modern browsers no longer trust certificates for which there is no (cryptographic) evidence of logging to CT.
The net result is that CT gives us visibility into all web certificates (and more).
"The net result is that CT gives us visibility into all web certificates [...]" including not always the desirable effect of publishing information on hosts in the non-public part of the institution network...
It's true that sometimes somewhere up in management tier people are annoyed to discover that non-Corp employees can find out about the DNS name product-we-bought.internal.corp.example and thus might intuit that Corp bought Product-we-bought. Or even, less often, that big-city.branches.corp.example exists even though they haven't officially launched the new Big City branch of Corp.
And it's true that CT is one of the various ways people might discover that although it's probably not even the easiest.
But honestly did you consider calling that purpose-of-software.internal.corp.example instead? And maybe at least use code names for projects that are actually secret?
Instead of normandy-invasion.corp.example at least call it overlord.corp.example and now it's not obvious where you're landing and I won't have lined up all the tanks and guns ready.
Others have responded at a high level, but I'll describe both a very low level and even higher level answer.
Low level first. CT logs produce a cryptographic "receipt" for the logged item. This receipt is a promise to report the item to anybody who asks within 24 hours. Web browsers, including Chrome, Edge and Safari, want to see the receipt. They may collect some receipts and check the logs did indeed publish these items. So, technically to make your certificate work in those browsers you need to log the certificate and the log you use needs to publish it.
Very high level. Logging and obtaining receipts, then providing the receipt to a browser is extra work. So, if you sell certificates it makes sense to do this work for all your customers by default and just bake the receipts into the data they have. It's extra trouble to build a mechanism to sidestep this, and so there's often no reason to do so.
Anyone who gets presented the certificate can check if it is in the log, and if it is not the authority is exposed and can be held accountable by the parties that manage the root certificate stores (browser and OS vendors).
> Because secure browsers like Chrome require certificate transparency for it to trust the cert.
And if it was found out to be fraudulent? "Secure" Chrome would do f***all unless you're PayPal while "insecure" Firefox always checks if the certificate is still valid.
How can Chrome be considered secure if its "security" entails the equivalent of giving a shell on the PC of all users to a shady corporation like Google?
There is a better way than CT: DANE, with query name minimization to prevent MITMing of some domains (as opposed to none or all) by a malicious or compromised . or TLD.
DANE means you get a real PKI with real name constraints, unlike WebPKI.
DANE stapling can reduce latency, but doing DANE w/ qname minimization for most of the domainname being resolved has the property that you get to make life really hard for a malicious or compromised . or TLD. You get to cache a lot of results, so using DANE stapling for the stem of the domainname should still reduce latency a fair bit.
With DNS over TLS or HTTPS we're seeing that resolvers are willing to use TCP, which is one answer to the DNS amplification attack concern.
DANE stapling died in committee at the IETF; there's no solid answer for how to implement it in a way where an attacker with control of a root certificate can't strip it off a TLS session, and if you assume an attacker can't control a WebPKI root certificate, DANE isn't serving any purpose either.
Meanwhile: DANE and CT don't have the same functionality at all. DANE defines away the need for transparency by saying that the PKI will be operated by entities we all intrinsically and completely trust (world governments). CT says "we don't trust the PKI at all, so let's log it". A lack of any kind of DANE transparency log is one small reason among many that DANE isn't taken seriously.
DANE (and generally anything that depends on DNSSEC) is dead technology at this point, with zero adoption in browsers. Arguably it offers less protection against malicious TLD or root because you don't get any logs. (well, you could require both with PKIX-EE mode, but that's getting really complicated to configure)
Browsers have refused to implement DANE for the last ten years. In the meantime, the major email players came up with MTA-STS, and alternative to DANE that cites lack of DNSSEC adoption as one of its rationales.
If you send email today, it's vanishingly unlikely that any DNSSEC will happen; email is complicated and email infrastructure tends to shut people's brains off (I know it does for me) but you can just look at the tiny slice of domains that are actually DNSSEC signed and see that there's no meaningful adoption.
I don't understand why you are being downvoted, since you are right.
For example: Microsoft has recently adopted DANE validation for outbound email, are planning to add TLSA records for their inbound email 'by the end of 2022. [0]
First of all, this is not worse than WebPKI. CT or no CT, you won't catch CAs MITMing you until it's too late, and even with CT you depend utterly on the sites you visit actually auditing CT.
Second of all, with DANE with QName minimization the parent CAs (zones) don't know what you'll be asking of the ones below, so either they MITM you for all your requests or none of them or they have to have other context to decide when to MITM you. The one bit of context they really want but don't get to have -if you minimize queries- is the full domainname you're trying to resolve, so it's hard for them to decide whether to MITM you. And you can catch DNS zones lying because you can a) perform the same lookups in different networks, b) you can download, cache, and check . and TLDs so you can catch those lying (which is 99% of the battle).
But most importantly, you get real, strong name constraints.
> CT or no CT, you won't catch CAs MITMing you until it's too late, and even with CT you depend utterly on the sites you visit actually auditing CT.
You won't catch a malicious nameserver operator, if they wish to MITM a specific victim, ever. There's no monitoring at all. While utterly depending on the fact they even enforce DNSSEC.
What's worse is that DNSSEC keys tend to live very long, if those are compromised, it will probably be abusable for years.
> a) perform the same lookups in different networks, b) you can download, cache, and check . and TLDs so you can catch those lying (which is 99% of the battle).
But if you're not the victim, it's unlikely you'll ever notice as a site operator. CT in that sense is different and much better as you can't rely on end-users reporting these things.
DNSSEC right now is a much much worse PKI than WebPKI is.
You don't control the entirety of your web stack, and your hosting provider, or DNS provider, or someone else, has decided to be 'helpful' (either blindly, or due to some misconfiguration somewhere along the line) and issue a certificate on your behalf, as they are able to intercept CA validation traffic at the DNS, TLS, or HTTP layer.