Anyone who thinks this is that trivial has never worked in enterprise IT.
Automated certificate renewal is maybe supported by 10% of services I operate where I work. And we're pretty modern. An organization with more legacy platforms is likely at "nothing supports automated renewal".
We are a decade or two out from 47 day expiry being a sane concept.
This is exactly why CAs are slowly reducing cert validity.
With a 47-day validity already on the calendar for 2029, nobody in their right mind is going to onboard a new service/device without automated renewal in 2026. Same with any kind of contract renewal: are you going to risk staying with the current vendor who is "considering" supporting ACME "at some point in the future", or would you rather ask their competitor who already supports it to make you a nice deal to convince your manager?
Sure, automated cert renewal might be supported by 10% of services right now, but what is that going to look like a couple of years from now when 100% of businesses are pestering their vendors for it, and leaving for competitors if they can't deliver?
> nobody in their right mind is going to onboard a new service/device without automated renewal in 2026
We're talking about people that didn't bother about an event scheduled in 365 days.
Why would they care about something that may happen in 2029?
No later than last week I had to setup a service using a 365 days cert that was provided to me as a ZIP archive.
The provider have everything in place to set automated renewal.
But they decided against it because it forces providing us with (scoped) API access to the provider.
Instead they put a reminder in Outlook and forgot about it.
Hopefully in ~50 weeks from now someone will see the reminder, decide to act on it, find someone available with access to the provider to renew the certs and someone available that'll read the doc I had to wrote explaining how to put new certs in place, someone willing to schedule the operation... all of that before the certs do actually expire.
Can confirm. Have encountered many on-prem and lift-and-shift solutions with no automated means of updating certs. The worst contenders are usually 1) executables on windows server (version 2012, of course), 2) old, obscure or very outdated database servers and 3) custom hardware firewalls. They are the worst.
To make things easy they usually all use different cert formats as well, requiring you to have an arsenal of conversion scripts ready.
Even plain IIS still doesn't support ACME on Windows Server 2025 without you grabbing some random scripts off the Internet written by people you don't know.
But yeah a lot of Windows server software uses inbuilt web servers with no ability to tweak or tamper beyond what the application exposes in its own settings panel.
In this case, “custom” means firewalls made by pretty much any of the major vendors.
Cisco, Juniper, Fortinet and Palo Alto have a lot to answer for with their laziness. Cisco and Fortinet added support only recently. Palo and Juniper haven’t bothered at all.
Turns out ”bank-grade security” is not something to strive towards. In the case of TLS certificates, most banks still believe they need EV certs, even though browsers stopped making any visual distinctions for EV certificates around 2018-2019.
Apart from the fact one dev as a test exploited a loophole to make a single sort of convincing EV cert (which could easily be fixed by a policy change), EV certs are still vastly harder to exploit or clone than almost any other certificate. The eventual solution will be an EV cert that isn't named an EV cert so that the CA/B can protect their reputations for claiming they're a bad idea.
The fact the browsers stopped recognizing this is political, not based on any reality of sense. Everyone appeals to authority what the best way to do TLS is, and the problem is the authority is stupid.
It can't. Nothing is guaranteeing that organization names are globally unique, so getting an EV cert for a conflicting org name will always be possible. Well-known counterexamples are Apple (Beatles or tech company?), Nissan (computer repair guy, or car maker?), and Microsoft/MikeRoweSoft (some guy named Mike Rowe, or software giant from Redmond?).
Unless you're willing to retroactively cancel a massive number of trademarks, EVs with human-readable company names are not going to happen. The best you can do is some kind of unique company id, but who's going to check that "US0378331005" is the right one?
A flag of the country? Each US state has its own company register. A flag of the US state? Who is going to remember which company is incorporated where? Can you tell US state flags apart when they’re scaled down to a height of ~20 px?
This is kinda looking for loopholes not recognizing the core reality of the situation. In addition to EV certs having a cost, you likely have to have a DUNS number which is globally unique, and that is a registry which can appropriately attribute you to a given country.
Is there many a hypothetical scenario where you could register a business, get a DUNS number, go through EV verification, be situated in the same country, somehow nobody stops you from registering an additional company called Microsoft?
...Maybe. And after spending a decent amount of money and leaving a massive trail of breadcrumbs to your identity with several different institutions, you will get sued, arrested, or both.
Meanwhile anyone can get a free Let's Encrypt cert for mlcrosoft.cn.
Also, legal names of companies can sometimes not match the well-known brand, making it harder to decide if the EV cert was issued for the correct company.
Is there any evidence of EV certs actually helping prevent phishing back when browsers showed them much more prominently? Or did users just not care/understand the difference?
The real fun starts when you have to do an unscheduled renewal!
Companies are generally able to develop a workable process around regularly-scheduled tasks. If you can't, you'll quickly run into trouble due to late salary payouts or missed tax filing deadlines. They'll rapidly accumulate a thick layer of bureaucracy around it, but as long as it gets exercised regularly it'll remain more-or-less functional.
Try the same with PKI and you'll run into massive issues during mass revocation events. Having a renewal process which takes 2 months and involves dozens of stakeholders is totally fine for a cert which gets renewed every 12 months on a well-known date - but not when you're working with a 72-hour deadline...
As well as having; proper documented (and tested) procedures and appropriate level of staffing/staff availability (not overburdened by juggling too many tasks and projects) - AND... keeping staff over several period/activity cycles, so they have actual experience performing the ongoing maintenance activities required. Oh - and heck, even a master calendar of "events" which need to be acted on, with - ya'know reminders and things...
Yeah - I have almost never seen any corporate or government environment actually take a "forward-thinking" approach to any of the above...
Certificate expiration notifications are a checkbox in uptime-kuma, which is itself incredibly easy to install and configure. We're not talking a week, we're talking a matter of minutes to go from zero to receiving notifications 21 days in advance of certificate or domain expiration.
Right now, today, the US government and it's three letter agencies are being run by a club of human trafficking peodophiles and rapists. Not individual, isolated, crimes. An organized group of very twisted people, having 'immigrants' rounded up and killed, pushing women back into the 1920s, and trying to make anyone who strays from heteronormative a criminal.
Having some independent developers in the defence market is not necessarily a bad thing.
Which is funny because they are the most AI replaceable humans in the building. Their entire function is to follow the corporate decision tree to the letter and make sure that all communication upwards gets filtered through their outlook account.
This. Add some agents installed on employee's PC and AI could have exact picture of whole company at any given time, without these weekly managerial meetings - status relays. No politics. No overseeing. If everyone works remote, the better AI is, because all communication channels could be monitored. Perfect estimation, almost perfect allocation of resources.
The point of being the boss is getting to decide who to replace with AI, tbh. The shareholders may not replace you because of relationships/trust/accountability, and also because they don't want to have to be instructing the AI day-to-day (or arguing among themselves about it).
Maybe this will change in the future if AI-run companies emerge, get backing, and outcompete existing players.
Debian, Ubuntu, Suse, and Fedora have had a bug free desktop experience for years. If you stick to the default repositories and use last year's hardware everything just works.
Whether it's a giant corporate model or something you run locally, there is no intelligence there. It's still just a lying engine. It will tell you the string of tokens most likely to come after your prompt based on training data that was stolen and used against the wishes of its original creators.
Factory reset an old phone and leave it in airplane mode.
If it get "lost" or "stolen" you aren't out much, and it doesn't contain any personal information. If "law enforcement" gets their hands on it the only data it has is the IMEI and maybe wireless MACs, enough to ID you based on previous use but they would have to contact telecos and request the info. Current "law enforcement" seems too chaotic to spend time tracing the owner of an empty phone.
For a detailed discussion about phones, personal data and anonymity, there is a good book written by a former police officer: Michael Bazzell (2024) Extreme Privacy: What It Takes To Disappear, fifth edition.
I'm not an expert in digital footprint-hiding, but it's probably a good idea to replace / remove the SIM card as well. A factory reset will leave data laying around, just not accessible through "normal" means.
On any modern phone, your phones user partition is encrypted with a key that is itself encrypted by a key stored in the CPU. When you factory reset, what's happening is basically the key in the CPU is deleted, then re-created. At that point the data on your partition is random noise, so a new encryption key is derived and used to format the partition.
Even better, modern Android then encrypted your personal data with yet another layer based on your password/key/pattern you use to unlock your device. Many layers.
Retrieving that data would be incredibly hard even for a nation state unless the encryption used was deliberately backdoored, and even then once the device TRIM's the space (which it likely does prior to formatting) that data is gone on a hardware level.
(TL;DR Can't move the memory chip to a new device, and even if you backdoor the OS you still need the users password)
It blows me away that a bank can't afford to do for themselves what Certbot and Lets Encrypt does for me, for free.
Like, pay a guy a whole week to automate this and it will save you the 12hrs losses every time your cert expires.
reply