[hedora]

Yes. This.

In particular, the company operating the data center your server is in can reliably do this, and so can the backbone provider they use, and probably the server's local government. The DNS provider that controls your domain can mitm the ca process too (though with a higher chance of detection).

The argument for making domain validation yellow (and not red) is that domain validation protects against attacks from residential ISPs / coffee shops, and it would also be hard for a foreign government to launch the attack against their own citizens. They basically have to compromise the CA, tamper with your browser, or just randomly break https with "bad certificate warnings".

Over time, I'd hope more bad security practices (crypto related or not) would lead to yellow bars.

For instance, intel secure enclaves help cloud security a lot, but they are still exotic. If they catch on, and you're at a vps that doesn't offer something like that, then you get a yellow bar starting in 2027.

[pfg]

It's hard to say if you're implying this is any different with other validation levels like OV and EV. The validation methods that CAs may use for OV/EV are the same ones they may use for DV. The only difference is that they also validate the organization's information of the certificate requester. In other words, someone with the ability to MitM traffic between the CA and the target's domain could still obtain an OV/EV certificate for that domain, they'd just have to verify they are who they claim they are on top of that (and they don't have to be the domain owner - there's nothing that says "only the legal entity owning the domain may acquire a certificate for that domain").

[nandhp]

> The only difference is that they also validate the organization's information of the certificate requester.

Right, but if I go to PayPal.com and the address bar says "Comcast [US]" or "National Security Agency [US]", I'll know something's up.

[rocqua]

Most of these issues aren't there with DNS based validation (presuming DNS-sec).

Though, that just shifts the potential problem towards anyone in the DNS-sec chain of trust. Most notably, the controller of the TLD (most often a government) and the registrar.

Thing is, those are also an issue with normal (http based) DV. After all, they could also change the A record for the domain they want a cert for.

I believe the current solution to all this is focused on detection rather than prevention (through certificate transparency and similar proposals). The idea being that any organization that isn't trustworthy will only get to pull of this hack once, in a short time frame before having their trust revoked.