...do you? Unless the attacker has access to the private key associated with the SSL certificate, they can't read any HTTPS traffic encrypted via that certificate - mitigating the ability of that bad actor to perform a MITM attack.
The effectiveness of CT logs isn't a thing unless the website uses CT monitoring or is a huge company. A [delegated or non-delegated] DNS takeover, or IP address release (eg. cloud providers re-assigning an IP to another customer) could allow you to generate a certificate for some-forgotten-subdomain.medium-sized.company.com using the ACME http challenge. Of course this is mitigated by properly managing your DNS, and CT monitoring is encouraged everywhere.
In other words, the effectiveness of the CT logs is a thing. There are multiple services which will do this for you for free (Cloudflare and Facebook at least make it trivial to get notifications for your domains) and it’s a level of visibility which almost nobody had just a few years ago.
crt.sh offers a RSS Feed, I use that to track all certificates issued for my domain. Doesn't really need anything expensive or complicated.
CT Logs don't mitigate any of the attacks but they make them very very very visible if they happen. Especially if a CA goes rogue, this will be immediately visible and provable.
IF you pin services to a key you control this mitigates the problem with bad guys obtaining bogus certs, BUT now you need to manage the pinning application to ensure it knows about any new keys before they roll into use. This may force you to compromise on your rotation schedule, maybe you'd prefer to use new keys for the new cert you're buying this week but alas the new app version is still waiting for Apple sign-off, so it'll have to be next year instead.
IF you pin to an intermediate key, which is under the control of a CA, then bad guys who obtain certs from that intermediate will not be inconvenienced by your pin, but these keys are intentionally long-lived (they are protected in an HSM) so the rotation issue isn't as fraught.
Well, no, the CT Log will include any valid certificate presented so any widespread attack will have to outright block access to the CT Logs or you're gong to have a bad time.
Expect-CT only controls if the browser will warn the user if the cert is not in the logs, it does nothing about certs being entered into the CT Logs themselves.
The above poster is still technically correct though, getting the cert is just 1 more obstacle in the way of the attack, which isn't as much of an obstacle as one would think for some actors(see China).
Certificate transparency would make it blatantly obvious if Chinese CAs were issuing bogus certificates. (And if they issued certs without submitting them to CT logs they wouldn't be accepted by Chrome or Safari, so it wouldn't be very useful.)
Sure, they could do it, but it wouldn't be long until there were no Chinese CAs trusted by any browser.
An attack like this could still be done for CLI clients/library clients such as curl (ie. server-to-server connections), none of which I'm aware of incorporate CT log verification.
You can add CT checks to such software with e.g. ctutlz (a Python library towards this end) but you need to be on the sort of treadmill that browsers are on, with regular updates and disabling security features like CT checking in browsers that don't get updated in a timely fashion.
All the non-Google modern CT logs moved to rolling annual logs. Cloudflare's Nimbus for example, is actually logs named Nimbus2019, Nimbus2020, Nimbus2021 and so on. Nimbus2019 is for certificates that expire in 2019. Most of them are already expired 'cos it's November already, it doesn't see a lot of updates, in January Cloudflare can freeze that and eventually they can decomission it, browsers will stop trusting it, but it won't matter because those certs already expired. If you go get yourself a new Let's Encrypt cert now, it'll probably be logged with Nimbus2020, come January 2021 you won't care if Cloudflare freezes it and starts shutting it down.
As a result you need frequent (say, monthly seems fine) updates to stay on top of new logs being spun up and old ones shutting down, or else you'll get false positives.
For CLI or server software that has a regular update cadence anyway I can see this as a realistic choice, for a lot of other software it'll be tough to do this without more infrastructure support.
But the server can’t do header checks for CLI tools prior to certificate negotiations, so it would be difficult to get away with. Not impossible, but it’d limit your Targets to IPs who are exclusively non CR clients. Any slip up and you’d be busted.
