1: I'm seeing names like "Actalis", "Baltimore CyberTrust", "Cetrum" - some of these sound more like pharmaceuticals than tech companies...
Taking the first one: AC Camerfirma S. A.
I suspect I've never authenticated anything against that CA. I'd love to know what sites it has authenticated, and maybe I'd be happy with a lot of .es sites
Wouldn't surprise me if I rarely if ever encounter 80% of the CAs that I trust. Looking through I'd be happy if some of the signed .ae, or .cn, but not .de.
If I did visit an unusual CA, I'd like to make a judgement call on that access. Sure, the big ones (letsencrypt, globalsign, etc) woul dneed to just trust completely, but having a "you are visiting youremail.com, last time you visited this was signed by Globalsign with a certificate expiry of 5 months time, today it's signed by Odd Looking CA, continue?
Sure for 90% of users would click though, and it shouldn't be an option for 90% of users, but I'm not 90% of users.
Same with importing. If I make my own certificates for my own stuff, I want to import my CA and trust if for .mydevdomain.com, but not for mybank.com, because I don't trust my own security enough to have anyone, including me, have a skeleton key to my entire communication chain for key sites.
AC Camerfirma seems to operate multiple CA certificates (e.g. some labeled by year). Here's a search that finds certificates issued by one of them: https://crt.sh/?Identity=%25&iCAID=51020
by contrast, the ca you chose to sign your cert can revoke it, or refuse to renew it, taking your website permanently offline with zero effort on their part, unless you can find another ca to sign a new cert for you
but if you could, let's encrypt wouldn't have had to exist in the first place
the dozens of companies you mentioned make that less of a threat, not more of one, though they do of course increase of mitm attacks as i described in the first paragraph of this comment
DNS or host/IP control is not a requirement at all: a Trusted CA is already trusted to sign a certificate for any hostname (with exceptions): that's what Trust means, and it also means that we trust them not to issue certificates for domains/hostnames without doing at-least Domain Validation - and we have schemes like Certificate Transparency to help bolster that trust, but it still doesn't prevent an already-trusted CA from issuing its own certificate for, say, google.com or microsoft.com. This is why techniques like Certificate Pinning and co/counter-signing, and others exist - but they're only useful when the client isn't a human-operated web-browser ("smart clients", "IoT", etc). EV certificates were (amongst other things...) meant to help protect against small-time crooks but again, don't help when the CA itself is compromised.
but, as i said, if you can feed me fake dns results so i connect to the wrong ip, or if you can arrange so that packets to gmail's legitimate ip go to your server instead (for example by having me connect to your wifi), then you can leverage the fake certificate into a successful mitm attack
but your explanation of the part of the basics of tls you understand, incomplete though it is, is irrelevant to the attack i was actually discussing, where someone doesn't like what you're saying (or the communication service you're providing) and gets your cert revoked to shut you up
Unless a router is compromised along the route, which is a known thing, and part of why we use ssl everywhere now.
the grandparent comment https://news.ycombinator.com/item?id=34629050 also describes some more common ways that this can happen without routers being compromised