[josephg]

> But there's enough places that can't set up automated processes

Why can't they be automated?

And anyway, this is the exact problem that short expiration times avoid! Systems that aren't set up for automation, and rely on someone once a year remembering some creaky, error prone process to get a new cert. Much better to force short expiration times so manual cert renewal is a thing of the past.

[Eduard]

> Why can't they be automated?

E.g. because of regulatory requirements, chain of responsibility, a paper has to be signed with a pen, etc.

[orra]

Interesting, but that sounds like speculation. Do you have any examples of regulatory requirements, as opposed to voluntarily-broken internal processes?

[Uvix]

The people installing the certs aren't necessarily the people buying the certs. I can't do anything to automate the cert purchases at my current workplace; that's a separate team that I have no control or influence over.

Shorter expiration times just mean they send me an email with the new .pfx every 4 months instead of every 12.

[TheCoelacanth]

If they had to do that every 2 months instead of every 12, they might get tired enough of it to fix their broken process.

[technion]

Several of the appliances we manage have certificates that are installed using a Web gui and require a reboot with a 15 minute outage for the change to take effect. We've looked at automating some things but there's only so far I want to go down the rabbit hole of headless chrome vs manually installing a cert yearly.

[pxc]

It seems like enforcing faster rotation would do a lot to encourage people and companies to move away from such obtuse platforms, no?

[voytec]

DV is not the only kind of certificates validation. I don't want to have to go through the OV/EV validation process several times a year, nor to validate 4 certificate issuances a year in advance.

But if I wanted to, I can do so even now without being forced - request new certificate during it's validity period, and revoke the former one.

[Kwpolska]

DV is the only kind that actually matters. Browsers do not display EV certificates in the address bar anymore, the verified identity is hidden in a panel or sometimes even invisible. If you want to pay extra for snake oil, you get to enjoy all the pain in the process. See also: https://www.troyhunt.com/how-everything-were-told-about-webs...

[citrin_ru]

Google made quite a few questionable changes in Chrome (with the rest feeling forced to follow the fashion set by Chrome) and not displaying EV info. Many big organisations use tens of domain some of which look very suspicious. Information in a EV/OV cert is often the only way to establish that a domain operated by the legitimate company (and not by a phisher who registered a similarly looking domain).

[cedilla]

Google and Firefox made the change roughly at the same time -- because there was a lot of evidence that EV indicators simply don't work. Users don't pay attention to them, and even if they did, the idea that company names are unique - even within a jurisdiction - is simply incorrect.

The only upside of EV certificates is that the PKI companies can seek a higher rent.

[citrin_ru]

Even if a higher price is the only EV difference (which not exactly the case) it would be enough make sites with EV certs much less likely to be used in phishing - threat actors want to keep their cost down because they frequently register a lot of domains (much more than most legit companies). And even company names are not unique good luck with registering PayPal Inc or Bank of America Corporation to get an EV cert for your phishing site.

[josephg]

I don’t understand. Why would phishing attacks bother getting EV certificates? Users can’t tell the difference in modern browsers.