In addition to domain+cert verification, you can type in "visa.com", scroll down to the footer, click "Privacy", scroll down to and click the "Visit Additional Privacy Information" button, then read the last paragraph of the second-to-last question, which links to this same page.
This certificate is actually OV. It has a Certificate Policy OID inside it, which is 2.23.140.1.2.2 for OV
This is set side in section 7.1.6.1 "Reserved Certificate Policy Identifiers" of the Baseline Requirements, although you could just Google it because OIDs are unique.
Cloudflare, as issuer, have confirmed that Cloudflare, the certificate subscriber, are really Cloudflare, because they're the same entity. That's actually an allowed shortcut, and, I'd argue, one of the most secure possibilities for such validation of business entities.
If you were wondering if this is really Visa that doesn't help you at all. For that you'd best rely on the fact that visa.com is the domain you care about and so logically Visa must have authorised Cloudflare to serve this name.
The predecessor of this site, back in summer, was not on Cloudflare, that too had an OV certificate, but for "Visa International Service Association" in Foster City. I guess somebody decided that letting Cloudflare handle this was cheaper/ easier.
> It has a Certificate Policy OID inside it, which is 2.23.140.1.2.2 for OV
Ah yes, thanks for pointing that out.
I'm not sure there's a practical distinction between EV and non-EV certs any more anyway. Browsers no longer show any indication of difference, and customers are not likely to inspect certs.
From a risk perspective, it looks like Visa is all-in on Cloudflare for consumer-facing infrastructure:
* Cloudflare terminates visa.com TLS, so it would be easy to swap an origin server without attracting notice, even if the cert was pinned or otherwise monitored
* Cloudflare also operates registered nameservers for visa.com, so they could issue DV certs at will
It looks strange, but it makes some sense. Visa deals with imperfectly-compliant handlers of cardholder data as their business, and they obviously have all sorts of risk modeling built into those relationships.
I'm sure they require Cloudflare to certify to a high level of PCI-DSS, and have carefully-apportioned liability in all of the paperwork.
> I'm not sure there's a practical distinction between EV and non-EV certs any more anyway.
I believe EV user interface treatment is still a thing in Internet Explorer, and for all I know the Chromium Edge has it too, I never run those browsers. Some minority browsers also distinguish, mostly using the CA/B reserved OID whereas historically Firefox and Chrome had a list of issuer specific policy OIDs flagged.
From the issuer's point of view, the generic EV OID is reserved by that same document for certificates which obeyed the BR rules for how to identify the name, business number (if appropriate) and location of the business, but that is not so different from OV. Private OIDs might correspond to some other (potentially stricter) policy.
There is another CA/B document about EV, but in practice reform has mostly taken place in the BRs and so rules there, or enacted by the trust stores (e.g Apple's 398 day rule) make most of the provisions of the CA/B EV rules obsolete.
The original goal of EV was to find a mutually satisfactory way to improve on the status quo at that time which was a price free fall for long-lived domain validated certificates using whatever method satisfied the issuer's needs to confirm control over the names issued. The browsers got issuers to do a better job (their main ask) and the issuers got a cool UI (the "green bar") to help sell expensive certificates.
The most important legacy of that was the standing meeting, the CA/Browser Forum, which means there is an ongoing dialog between the CAs and the browser vendors rather than them only talking when there's a grave and urgent problem. It took some work to design a structure that's legal, that gets the job done but isn't a cartel, because cartels are illegal (OPEC is/ was a cartel but its members are sovereign entities, and so they are immune to prosecution for running a cartel)
There's considerable value in being able to get the other participants in an ecosystem to agree (even if begrudgingly) that a policy change is necessary rather than forcing it upon them. Getting to 825 day certificate lifetimes was done by agreement, and not even so very long ago, while 398 day lifetimes was done by Apple's fiat after they struck out in negotiations.
Visa doesn't have to worry about PCI-DSS, unlike a retailer who is going to "stop" Visa from doing stuff that is prohibited by PCI-DSS? Nobody. Like the banks, the networks gave themselves the independent right to decide to just break the rules if they want to. For example if your e-commerce website uses SHA-1 that's a huge No-no right? But if Visa has a system that uses SHA-1 and replacing it to do SHA-256 would cost say $1M, they can decide actually it's fine as it is, they keep the $1M and that's OK under rules they helped write.
Legitimate question to ask if asked correctly. Companies spend non-trivial amounts of money trying to train people with pseudo-phishing emails and basic web navigation skills, and your question/statement, while unfortunate in its wording, is a good question to ask.
And this was somehow brought to the front page of Hacker News?
This is a very low effort scam. At least put in some effort beyond your dozen shadow accounts on HN.