Certainly, but depending on the type of attack, that might not be of much use. In a targeted attack, the damage might already be done by the time the certificat

Certainly, but depending on the type of attack, that might not be of much use. In a targeted attack, the damage might already be done by the time the certificate is detected. Additionally, revocation as a whole is broken in various ways[1], not to mention that even with hard-fail revocation checking[2], you have a window of several days during which you can staple a "good" OCSP response, from before the certificate was revoked. (The exact lifetime is up to the CA - I think the maximum allowed is 7 or 10 days.) CT, as currently implemented, is good at two things: Detecting misbehaving CAs, and detecting certificates issued by attackers after a server is compromised or domain is hijacked, assuming the domain owner is monitoring logs for such certificates. The Web PKI does not provide many tools that actually mitigate damage for the second scenario (unless you've deployed HPKP, which is on its way out). [1]: https://www.imperialviolet.org/2014/04/29/revocationagain.html https://www.imperialviolet.org/2014/04/29/revocationagain.ht... [2]: Practically no mainstream browser uses hard-failing OCSP. Firefox supports the X.509 Must-Staple extension, which enables hard-failing OCSP, but Must-Staple has a glaring hole: If the attacker gains the ability to issue a certificate for the targeted domain, they can simply request a certificate without the Must-Staple extension. Must-Staple's usefulness is mostly limited to key-compromise scenarios.