I.e.:

> An Extended Validation (EV) Certificate is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. EV certificates can be used in the same manner as any other X.509 certificates, including securing web communications with HTTPS and signing software and documents. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity's legal identity before certificate issuance.

* https://en.wikipedia.org/wiki/Extended_Validation_Certificat...

Arguably in the extremely early days of SSL this is how it works, because the Certificate Authorities have never done this before and so sure, we fly our account excecutive out to your New York HQ and they sign (with a pen) a contract for $5000. Those early certificates are, by modern standards, worthless garbage, Chat GPT can probably teach you how to forge one though it might be too expensive for an amateur to do at home - but they do have street addresses and so on if you cared to read them. A web browser of course did not read those street addresses, and it has even less idea than you do whether the details correspond to reality.

Within a few years at most the Race to the Bottom is well underway - if I spent $10 on my "streamlined" process to offer 1000 certificates for $10 each I make more money than a rival spending $1000 to offer 100 certificates for $100 each. As a result "Domain Verification" is normal by the turn of the century. If you weren't here for the Dotcom boom, you have never seen any of this. If you bought books on this stuff on Amazon, or worse you've never read any books about it because it was all online, you arrived after DV was everywhere.

A peer mentions EV, that and OV are actually newcomers, the CAs realised that customers don't want to pay $100 for a "better" certificate when customers can't tell the difference so there began a meeting, the CA/Browser Forum sometimes just referred to as "cab" or "cabf". This meeting had two initial outputs. One of them endures to this day and only got stronger:

1. Certificate Authorities must meet at least certain Baseline Requirements (the "CA/BF BRs") for all certificates. You can't issue certificates which do not meet these requirements, putting a floor on how terrible your verifications can be.

2. Browser Vendors will add shiny UI for a new "Enhanced" verification certificate so that customers can see it's better and that's a new sales opportunity for CAs.

In practice after some years (2) stopped making sense. A shiny UI works on a desktop PC but there's no room on an early smartphone, so you just don't add this. Soon enough you make Desktop browsers look the same as your smartphone product and all the time your UX experts are telling you users do not undertand this UI (no surprise it was just a sales gimmick) and Safety experts are telling you that it's a net negative for user safety. So, bye bye EV UI in browsers.

But the other side of the bargain went very well. The BRs were a ratchet. In 2012 a ten year certificate issued based on some sales guy who met the director of a company at lunch was fine. By 2016 even five years is clearly too long and we should check some actual official records or have some kind of formal process. In 2012 it's fine to issue for mysql.test.internal because that's not a public name right? By 2016 uh, no, that's why it's not OK to issue that certificate, nobody could possibly own that name, do not issue bogus certificates, this is Serious Business. The BRs are how, gradually, we got where we are today.

I went through the standard validation many times and the entire process felt like a security theater. For example, I had to upload a scan of my ID, but I know for a fact that in my jurisdiction no private entity can access government databases to validate that it is a genuine ID and not a photoshopped image. The government provides a SSO that third parties can use, but none of the main cert issuers implemented it, even for EV certs. They just trusted a JPEG.

It's like those arcane verification checks used by US-based services that ask for utility bills, as if they had any way of verifying an invoice issued by a small utility provider in rural Finland.

> http-01

Good point, I forgot about that! But then CAA record might help, I guess, if you specify your accounturi?

http-01 seems absolutely unreliable, any hosting provider or any government can issue fake certificates using it. What a garbage technology.

I don't see how you can have actual "proof of domain ownership" without secure DNS, or some kind of similar PKI. Right now they don't check for proof of domain ownership at all, just whether you have temporary, de facto control of the DNS record or the network it points at. This usually works well enough, but won't do anything if a MITM attack occurs on the server side rather than the client side.