I remember doing validation calls with Verisign in Switzerland to get an “extended validation” certificate for a customer. It felt like applying for a passport. We had to fax them stuff too IIRC.

Now I issue 100 certificates per day fully automated for customers using Caddy and LE.

Indeed a legacy. RIP.

E.V certificates are alive and well.

And don't even get me started on EV Code Signing certificates :(

That said; it is indeed a lot easier to do TLS/SSL today; even the standard "DV" certs were not fun and at larger companies was a near-fulltime job.

Wait, really? What are EV TLS certificates actually used for nowadays since all browsers deprecated the "green bar" UI?

Yep.

Green bar is an implementation detail.

The main draw of EV certs is the insurance you get, I think it’s even still part of PCI-DSS

I do not recall having to get EV certs for PCI. Our auditors were always fine with the Geotrust/Digicert DV certs. Is this part of the 4.x spec? Can you link to the requirement for EV certs?

Not really, but a large number of auditors (not sure if it's "most" but it's still surprisingly many) do insist on EV for some reason (and as you point out, it's not even mandated in the spec itself, at least the current ones). The insurance aspect, well it depends, our lawyers said that "insurance" on EV products (by DigiCert and Globalsign at least) are simply legalese garbage but I can remember a broad-spectrum cyberinsurer insisting on EV certs. Oh well, it's ultimately their territory, not ours.

Edit: thanks for reminding me that PCI-DSS 4.0 is now released - but it only states that you must securely deliver sensitive information over open networks (including internet) and explicilty bans all SSL versions and TLS lower than 1.2, which is the same as 3.2.1. It even references a NIST document which shows methods for automatic cert issuance featuring Certbot (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...).

For what it's worth and given there is risk in doing this, but one can work with their contacts at the payment processor to manually pin certs on both sides. There is operational risk and both sides have to be vigilant with monitoring and communication but that can be an even better assurance of transport security in some fringe PCI cases. I recall two of the major processors were open to this. No idea if they still are. I just would not put it in the internal official documented PCI or SOC1/2 controls or one would be stuck doing this. Could be useful as due diligence if legal are that nervous about the PCI environment. Maybe just documented in a JIRA or internal ticketing system.

Makes sense. I was just making sure I was not missing something or that it was not quietly added to a recent addendum/revision of the PCI spec.

That industry value would have surely multiplied given how search engines and browsers are devaluing/warning on non-secure connections.

Once you can figure out how to non-interactively renew those certs, it's fire and forget now.

> That industry value would have surely multiplied

Nope. The industry warning and devaluing unencrypted connections was enabled by low cost configuration and zero cost issuance.

There is almost no chance that browser vendors would have proceeded with "deprecation" of unencrypted HTTP traffic without free issuers; the response from businesses would have been overwhelmingly negative.

The big shift was done when Google said that they would start to demote sites not using https only.