4 ms·
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.
by tnolet 4y ago
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.
- dijit 4y agoE.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.
- Karunamon 4y agoWait, really? What are EV TLS certificates actually used for nowadays since all browsers deprecated the "green bar" UI?
- dijit 4y agoYep. 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
- LinuxBender 4y agoI 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?
- zinekeller 4y agoNot 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.SP.1800-16.pdf#page=173 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...).
- LinuxBender 4y agoMakes 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.
- LinuxBender 4y agoFor 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.