I remember a time when having an HTTPS connection was for "serious" projects only because the cost of the certificate was much higher than the domain. You go commando and if it sticks then you purchase a certificate for a 100 bucks or something.
https://groups.google.com/a/chromium.org/g/security-dev/c/h1...
You'll still find people online clamoring EV certificates are worth anything more than $0 but you can ignore them just as well.
The only good thing dealing with certificate resellers at the time was that they where really flexible in a lot of ways. We got our EV cert refunded, or "store credit" and used the money to buy normal certificates.
Nobody is like "Oh, the Jones Act ensures high quality ships" because it doesn't, the Jones Act just ensures that you're going to use those US shipyards, no matter what.
Extended Validation can still play a role in a corporate's IT control framework; the extended validation is essentially a check-of-paperwork that then doesn't need to be performed by your own auditor. Some EV certificates also come with some (probably completely useless) liability insurance.
[1] https://chromium.googlesource.com/chromium/src/%2B/HEAD/docs...
There are some scenarios where you still have to employ EV certificates, e.g. code signing.
If your DNS provider doesn't have an API, that seems like a separate issue but one that is well worth your organization's time if you're working in the enterprise!
We were looking for a SSL provider that had > 1 year old certs AND supported ACME... for some reason we ended up with SSL.com that did support ACME for longer lasting certs; however, there was some minor incompatibilities in how kubernetes cert-manager implemented ACME and how SSL.com implemented ACME; we ended up debugging SSL.com ACME protocol implementation.
Fun. We should have just clicked once per 3 years, better than debugging third parties APIs.
No, I don't remember the details and they are all lost in my old work emails.
(Nowadays I think zerossl.com also supports ACME for >1 year certs? but they did not back then. edit: no they still don't, it's just SSL.com I think)
Warranties / insurance on SSL certificates typically only pay out if a certificate is issued improperly, often in conjunction with other conditions like a financial loss directly resulting from the misissuance. Realistically, any screwup serious enough to result in that warranty paying out would also result in the CA being abruptly removed from browser root certificate programs.
I wonder if this would be an opportunity for revenue for Let's Encrypt? "We do 90-day automated-renewal certificates for free for everyone. If you're in an unusual environment where you need certificates with longer validity, we offer paid services you can use."
Why are (some) banks always completely clueless about these things? Validating ownership of the domain more often (and with an entirely automated provisioning set-up that has no human weak links) can only be a good thing.
Perhaps the banking sector will finally enter the 21st century in another ten years?
Not in any jurisdiction I'm aware of, though it's a big world so it wouldn't shock me if some small corner of it has bad laws.
> and also obligatory for rolling out as MasterCard/Visa merchant by their anti-fraud requirements
PCI DSS does not require EV certificates.
They have these really, really long lists what all needs to be secured and how. Some of it is reasonable, some of it is bonkers, there is way too much of that stuff, and it overall increases the price of any solution 10x at least.
But OTOH I can hardly blame them, failures can be catastrophic there, as they deal with real money directly and can be held liable for failures. So they don't really care about security, and more about covering their asses.
Lets not talk about key delivery. We will get back the admin cost and of all that in a year if we tunnel them through one of our LBs.
Some of it is truly bonkers and never was good practise, but much of the irritating stuff is simply out-of-date advice. The banks tend to be very slow to change unless something happens that affects (or directly threatens to affect) the bottom line, or puts them in the news unfavourably.
Of course some of it is bonkers, like HSBC and FirstDirect changing the auth for my personal accounts from “up to 9 case-sensitive alpha-numeric characters” (already considered bad practise for some years) to “6 digits”, and assuring me that this is just as secure as before…
I think there's still incentive alignment here. Getting people moved from the "purchase 1 year certificate" world (which is apparently still required in some financial contexts) into the ACME-based world provides a path for making a regulatory argument that it'd be easy for such entities to switch over to shorter-lived certificates because the ACME infrastructure is right there.
I read it as “we have been asked to integrate an ancient system that we can't update (or more honestly in many cases: can't get the higher-ups to agree to pay to update), so are bringing out other systems down to the lowest common denominator”. That sort of thing happens too often when two organisations (or departments within one) that have different procedures, merge or otherwise start sharing resources they didn't previously.
And another fun one unrelated to signing was when they tried to trademark "Let's Encrypt" in 2015.
But yes, it is not a common issue and effort would be better focused on improving site security in other ways. (unlike the rest of my comment, this line isn't sarcasm.)
One of the practices was pathetic to the point of being funny: you had to input specific characters of your password (2nd, 4th, 6th, etc - this was changing at each login) AND there was a short timeout. My children probably learned a few new words when I was logging in.
Some time later they silently removed the first one.