You're right that if you can get an illegitimate cert, the entire PKI falls apart. However, the cert has to match the domain, and certificate authorities will have their trust revoked by browsers (making their certs useless) if they're found to be giving certs away to people who don't actually control the domains they're for. Typically you have to at least control the e-mail for a domain to be able to get a cert for it. Large governments could probably get hold of illegitimate certs easily enough, but it's quite nontrivial for anyone else. And even for governments, a forged cert is inherently detectable, so any complicit CAs could be eventually found out and get removed from browsers' trusted lists.
This problem will potentially go away in the medium term with DNSSEC. Once sites can deploy certificates through DNSSEC, there's no reason we couldn't also devise a DNS record that says "only accept certificates from DNSSEC, not certificates that claim to be signed by CAs". Then the only way to publish a false certificate for the site would be to compromise their DNS, which gives you many fewer attack vectors than now, when you can compromise (or trick or bully) any one of hundreds of CAs.
There's been discussion about adding a feature like this to Strict-Transport-Security, so you can say "only accept a cert signed by this root CA". Then an attacker has to compromise a *specific* CA to compromise the site instead of being able to compromise *any* CA, making their job much harder.