Yes, but using a counterfeit certificate requires a much more active, targeted, and potentially-discoverable attack. With a counterfeit cert, you could pretend

Yes, but using a counterfeit certificate requires a much more active, targeted, and potentially-discoverable attack. With a counterfeit cert, you could pretend to be a target's email host, for example. But you'd need to be an active man-in-the-middle, and you'd only see information during the sessions you actively hijack. The target, or anyone else you mistakenly man-in-the-middle, might notice the changed certificate/authority, thus sounding alarms or clamming up. If exploiting heartbleed, in contrast, you'd be taking arbitrarily-many random samples of the email host's private memory, in a manner that even the email host's typical logging would not notice. Over time, you'd likely get many login credentials, app and SSL session keys, and possibly even the site's authentic certificate private key – that's something that even a faithless Certificate Authority can't cough up. (They can certify a fake private key... but they don't have their customer's true private keys.) At that point, unless PFS is enabled, all past and future SSL sessions could be decoded via passive eavesdropping. So if you had a choice between several collaborating CAs or most of the internet running buggy OpenSSL, you'd pick the buggy OpenSSL. And if you had both, you might very well use the heartbleed bug more often, because it's both less detectable and more likely to offer bulk data for analysis.