New SSL/TLS certs to each live no longer than 47 days by 2029 CA/Browser Forum – a central body of web browser makers, security certificate issuers, and friends – has voted to cut the maximum lifespan of new SSL/TLS certs to just 47 days by March 15, 2029. Today the certificates, which underpin things like encrypted HTTPS connections between browsers and websites, are good for up to 398 …
Man, people here are getting cynical...which is somewhat understandable, but in this case...probably not justified. Yes, TLS is the boogeyman for a lot of sysadmins, yes you can cause a lot of damage if you don't know what you're doing and yes it can be expensive depending on your requirements...but I don't think this is a cash grab.
I think a large proportion of TLS certs out there are free these days...this is just an admin headache if you manage your own certs...if you use CDNs like Cloudflare, Akamai et al, this won't make a difference at all.
I think getting rid of the old 5+ year certs is actually good thing...because it means systems won't be left to rot for as long with older versions of TLS and we'll see swifter action on upgrading / switching ciphers etc. The problem with long term certs is you end up with systems running outdated ciphers or an older version of TLS for longer than it should...getting away from TLS 1.1 was a massive pain in the ass and to a certain extent it is still in wide use...particularly on smart devices like TVs etc...isn't that right...AMAZON?! With your shitty old fork of Android.
It's not uncommon to find a cert renewal job that quickly turns into a full migration because you can no longer get supported certs for an old platform, which is one of the reasons I quite like doing certificate updates...it's a hidden gold mine that can lead to a lot of additional and crucially, chargeable work.
I do a lot of freelance stuff involving TLS/SSL (because for some reason, it's work that nobody wants to touch because I think it's still, even now when it's never been easier, seen as something of a dark art). Bosses freak out about it because a lot of them will have a memory of a certificate deployment / upgrade that went horribly wrong at some point and have flashbacks to errors that were confusing and difficult to decipher (natch)..."UNSUPPORTED CIPHER", "UNSUPPORTED BIT LENGTH", "CA ROOT CERTIFICATE INVALID", "KEY/CERT MISMATCH", "CANONICAL NAME / OU DOES NOT MATCH" etc etc etc...all really dumb problems and easy to fix, but with scary and jargon filled errors.
It's crazy how much you can charge to roll out / update TLS for folks. It's not as much money as it used to be, pre-pandemic you could charge easily £300-£400 just to properly configure TLS and roll out a cert on Apache / NGINX...mostly because you have that wicked scary combo for your typical sysadmin, it's Linux, Apache/NGINX and TLS all rolled into one spooky scary package and it's usually on a production setup with perceived risk of downtime, it's a lot of potential damage in a very short space of time if you fuck it up (which is actually quite difficult to do these days)...this is why hardly anyone takes those jobs, I very rarely have competition for them, sometimes I'll see the same names popping up dropping quotes on various sites, like a half dozen folks, one in particular (whom I've never met, I seem to follow around like a shadow, mopping up his messes)...you can still easily get between £100-£200. To be clear, for that money, I'd usually automate the process so the customer never has to think about it again or implement some kind of CDN in front of their web service with a 10-15 year origin certificate so they never have to worry about certs expiring...so it's not like I'm charging a hefty fee once a year.
I think professionally the industry has been somewhat turning a corner as well, because I know of quite a few folks that have been fired for actively avoiding Linux / NGINX / Apache stuff particularly involving certs...because I've been the one to step in and take over their role on a contract basis either as part of a wider team for larger companies or simply taking over the entire tech / architecture role at a smaller company...because paying someone like me £400 a month for essentially the same service without the hassle of having someone hanging around the office 5 days a week with a scheduled weekly/fortnightly site visit is preferable. That said, those that work on their Linux skills rarely get fired and replaced in this way...because they are difficult to replace...you can find cheaper contractors of course, but the skillset is still relatively uncommon...and there is still risk with contractors, because not all of them are on the ball all the time...I've never been ejected from a contract, it's usually my choice to leave either because I've gone an extended period without being able to raise my rates or I can see the company is running out of cash and I'll soon be in a position where I'm supporting a dying infrastructure that I can't do anything about without some investment in kit etc and I don't want to be there when it dies...but there are a lot of contractors that regularly get ejected for being crap, lazy, difficult to contact particularly out of hours, vanishing on holiday without notifying anyone, being a literal one man band with no backup cover / partner contractor, having no insurance etc...there are plenty of ways to fuck it up.
It is the boogeyman for the simply reason of shitty tools, it is justified. openssl iso_8601 took until V3 (somewhat bugfree since 3.1). The bad default cipher MD5 was way too long in the default config.MS-PKI is just as chaotic and admin friendly as openssl.
I agree with the rest though. I am one of the few in our company (3000+) being able to handle it, but I don't like it. And your example list of nice errors, which you can only decipher with openssl -text and check for the difference between the request, what the (customer configured) CA gives you, the root CA and so on in combination to see the actual issue... And then that way too many programs insist on different parts to be supplied in a different way, up to the "cert+privatekey+fullchain IN THE RIGHT ORDER !!!!!!!!!!" of some java crap... Usually you cannot take the "fullchain" supplied by the CA you pay for, you have to get those five parts and put them together in the only accepted, but nowhere documented, way, best with you favourite text editor, and carefully save as 8 bit and not UTF - or the other way around, insisting on UTF16 for practically a text file...
Did I mention that I don't like it ? :D...
When I was a rather fresh sysadmin I got asked to install a local Kerberos/LDAP login system for a few Linux machines. This involved generating certificates and keys and whatnot... I set the certificate age to 10 years and thinking that was about 35% of my current lifetime it would be good forever (ahem *cough* 10 years). Cue a few years back suddenly reports of logins not working, which seemed weird as I hadn't changed anything lately. After a bit of debugging it became apparent a certain 10 year certificate had expired - cue grasping around for my notes to make a new certificate. Except this time I've set the expiry shorter, made better notes and aim to refresh the certificate annually so as to have the procedure 'fresh'. So yes, shorter certificates get my vote.
Certs have nothing to do with TLS/SSL versions or the type of encryption used. The only algorithm is in what signed the cert. Should be nothing stopping anyone from running a cert issued in 2025 on a SSL v3 system for example (other than some clients may not like it).
Cert is used for identifying, nothing more.
Because you'll buy a 10 year certificate and never login to that box ever again other than after a powercut to make sure it started up...then about half way through when you get fired and someone else has to take over, the box is so fucking old and out of date that it becomes a living nightmare to manage or migrate.
10 year certs are dumb on many levels and the types of people that buy them are the same kind of people that don't document shit, they never run updates and they never...ever...under any circumstances...maintain anything in case it breaks and they can't fix it.
I used to nickname 10 years as "jobsworth certs".
10 years is an eternity in tech years...during pentests, when I've found servers with a few years left to run on a 10 year cert I've also found shit loads of vulnerabilities and exploits...it's one the things I actively scan for...and you can bet your ass hackers are too.
Same vendor, same TLS version, please explain to me how a three year cert is any way less secure than a 30 day one.
A cert is either secure, or it isn't. If there is an attack vector that can violate a public facing cert. I don't know about it and it's my job to know.
If 47 days is your cup of tea, then why not invalidate them after 47 minutes? No, that would be ridiculous, right? Yeah...
If time is such a massive threat why do the cert authorities themselves issue root certs of ten+ years.
Because some people in tech flagrantly ignore best practice, thinking "it's probably fine" on their never ending quest to do fuck all for their money.
How many times have you heard "Just whack a 10 year cert on there, we don't have to worry about it for years then!" and that same person being the guy that rarely logs into a server to check it? The next time that wanker does anything with that server will be following a disk failure, the drive filling up with logs or a power cut.
Anyone reading this that has servers with 10 year certs on that they haven't checked since the cert went in needs to login now. Do the updates. You fucking cretins.
"Because some people in tech flagrantly ignore best practice, thinking "it's probably fine" on their never ending quest to do fuck all for their money."
This is literally fascism: "Because some people are bad, we must punish everyone". Poorest excuse ever.
47 day is absolute bonkers: It's *all* for more money. And forcing people to use front ends like Cloudfare, which then steals them blind, again.
When they forced this same stupidity to passwords, we got just stupid passwords and *less* security.
Totally disagree...nobody implements a 10 year certificate for any reason other than they can't be arsed to do a renewal once a year or something or it's an area of tech that is at the fringe of their abilities and they're scared of it...if they can't be arsed to renew a fucking cert, what else can't they be arsed to do?
I've never heard a justification for a 10 year certificate that wasn't along the lines of "just get a 10 year cert then we don't have to worry about it for years". There is *never* a technical reason for it. The cost difference is neither here nor there most of the time because it's such a negligible cost most of the time anyway if you buy a commercial cert.
It's also worth pointing out that most places haven't offered anything longer than 3 years for a while now.
Finally, 99.9% of the time a long term cert is used as domain validation certificate or something...they're *never* used for authentication. Certs used for authentication should absolutely be rotated regularly. You should never use a long term certificate for authentication...that's just massively dumb on many levels.
As for the fascism claims, how is shortening certificate lifespans a punishment? If you find renewing and managing certificates to be difficult enough that you find it punishing, you're probably in the wrong job.
If it's a cash grab, who cares? As an operational cost, certs cost essentially fuck all or depending on who you use to get your certs actually fuck all. Also, it's not like us as techies are being robbed, its the companies we work for, and it's likely to be such a trivial increase in cost that all it amounts to is a rounding error. It's not like you're going to be making a hard choice between a new server or a certificate renewal. If you're concerned that your hundred separate sub domain certs are going to increase the cost significantly, get a wildcard certificate. Consolidate your certs into one cert. If you were willing to buy a 10 year cert purely for the admin overhead, then consolidating down to a single cert won't bother you at all.
Buying a long term certificate because you think you're saving money is a false economy, that's where the money grab is...because you'll never jump ship to another provider for a better deal. So the 10-15% saving you'd make on a long term cert will be far less than the 25-50% you can save by switching providers when there is a deal.
I also fail to see how regularly renewing certs results in less security. It's at least exactly the same security but the risk of your certs being stolen and abused for long periods of time without your knowledge greatly reduced so in theory, better security.
There are situations where a long term cert makes sense, like on a widely distributed product that cannot and will not ever connect to the internet to receive updates...lab equipment, test harnesses etc etc...but it's likely in that scenario you'd use a self signed cert anyway and ship the CA Root Trust certs with the product alongside some instructions.
I don't work for a CA no...but I do make a lot of money renewing certs for businesses and deploying new ones on the backend of development projects....as with anything in tech that makes money...TLS sits in one of those weird grey areas that people perceive as being complicated from the outside, but once you know how to do it, it's nothing.
In my 20+ year career, I've made more per hour taking on things like TLS deployments to things like NGINX proxies and Apache than anything else...I've rolled out some seriously insane shit in my time worked on some projects that have been years long...but nothing has made me as much money per hour as a certificate deployment...it's fucking insane...the best thing about it, is you can pick these jobs up on a whim...they're listed on freelance sites all the time...and a large proportion of them start out trying to use people that charge a fiver for a deployment, so by the time you get to it, it's been through 2 or 3 try hards that failed.
At it's base level, if you're just deploying certs to one site on a Linux box with Apache (which is 99% of the time) the process is:
0. Get the cert (obviously)
1. Put the certs on the server in a path that Apache can access.
2. Set the appropriate permissions on the PEM files.
3. Add 2 maybe 3 lines of config to the site config in Apache, or just edit it if its a renewal...basically the paths to the cert, key and sometimes the chain. Maybe you'll have to enable the SSL/TLS module if it isn't already.
4. Restart apache.
5. Send an invoice.
This can all happen in under 20 minutes...and for large scale deployments you can write simple shell scripts to automate it. The more certs you need to work with, the less time it takes and the more you can charge...and yet, vast numbers of techies won't go near it which is what pushes the price up!
> 1. Put the certs on the server in a path that Apache can access.
With Apache you've chosen the most simple example here. Apache is indeed very easy going. Getting the cert costs more time, scheduling "when can we restart the service" too.
If you've not yet come across examples which make you pull your hair out, I consider you lucky. See those many possibly errors one "Anonymous Coward" posted. I've not seen all of them, but I've seen enough of them :D. That AC posting does not deserve that much down votes though...
Edit: No wait: The most time costs getting the real-admin access to that weird java crap some are running, where the "admin" is account is not admin enough, and the have to get the "sysadmin", which take extra time. And then are picky handling over the credentials or are too stupid to log in for your on a remote session so they don't have to give you the credentials.
"this will generate lots of manual work"
It really shouldn't. I have no idea when my certs renew or how long they're valid for: they renew automatically and cost me nothing. How long they're valid for is about as important to me on a practical level as the fine details of the wear-levelling scheme used by the firmware in my SSD.
Domain-level certification (e.g., from someone like Let's Encrypt) is all anyone really needs. Before you harp on about needing a "higher level of trust" blah blah – nobody normal even actually knows what you're talking about let alone cares. Maybe there's some ISO 9000000001 shit going on that means your certificate needs to be particularly shiny, but it's all money-making nonsense in the real world and you know it.
My apologies for agreeing with Apple. I don't like it either.
I have a very small pool of domains, so it's not hard for me to check. But even in a larger organisation, it should be fairly simple to schedule in a basic sanity check on the renewals processes. This could even be something as simple as sending an email to a designated person every time a certificate renews, with part of their job being to check that the list of domains renewed doesn't include anything dodgy. The carrying out of this brief task and its result could then be recorded somewhere to make sure it was being done and for there to be somewhere to point the finger if it wasn't and something bad happened.
I have close to 800 registered domains (Not all of them are active, of course.) across nine countries, each with their own rules, regulations and government reporting / paperwork that needs to be followed. Anything with a link to a government department is a nightmare to coordinate.
Shifting to a validity period of a year is barely manageable. Some government branches have taken eight months to get approval for a change.
47 Days? No fecking way.
such a check would be the least of the worries, the most of the worries would be the cert install process encounters an unexpected error and leaves the system is a broken state, for basic web servers installing such certs is not too complicated, becomes more complicated when you have infrastructure services relying on certs. Some systems offer API interfaces to manage that stuff(or a CLI) but that is more complexity and I'd wager in some cases such interfaces aren't well tested because they aren't frequently used(yet anyway). Many embedded systems have to be rebooted entirely for the new cert to take effect.
All the time if I'm checking my inbox...your LetsEncrypt agent is linked to an email address and alerts you when a cert is renewed or generated...also at least once a week on the server, because I login to my servers to install updates and perform house keeping...like a proper sysadmin....it only takes a glance at /etc/letsencrypt/live...ls the folder, look at the domains, sip tea, check the timestamps...move on to checking / purging logs etc.
...and I do it with a fucking smile, because I could be a used car salesman, an estate agent, a traffic warden, the guy that empties dog shit bins at the local park...any manner of professional twat with a shit job...but I'm not...I'm a techie...and for that, I'm eternally grateful...if I have to spend 10 seconds checking LetsEncrypt from a fucking terminal...I'll gladly do it.
I swear some guys here think TLS is a full time job...it really isn't...I've smoked fags that lasted longer than checking LetsEncrypt.
I think a metric shit ton of techies live in constant fear that one day they might have to fix something.
>> the guy that empties dog shit bins at the local park...
After spending most of my life working with computers, writing code, dealing with assholes bosses, if I was looking for a job I'd be much happier emptying dog shit bins at the local park than returning to IT.
Same as I'm happy to take my neighbours dog for a walk (for free) when I walk mine several times a day. We do the rounds, meet other dogs, other people, get fresh air, exercise, they poop I scoop, it's much healthier than sitting in front of a for all day.
I'd rather pick up dog shit for free than go back to the dysfunctional world of IT. It's just not worth it no matter how much money.
Couldn't agree more. I'd love to drop out of the industry and do my own thing in tech (I'm almost there).
However, I don't think anyone doing their job properly in IT is sitting in front a screen all day. I don't, and I haven't for over a decade, and many of the folks I know in tech (quite a few at this point because I've been around for quite a while). Maybe once a week I have a full day at my desk...the rest of the week, I'm checking in for a couple of hours, doing some preventative maintenance for my clients, responding to requests and maybe half a dozen times a year I'm deploying new infrastructure, which might require a visit somewhere, unless it's shipped here for setup and I can ship it on to be plugged in at a DC somewhere by remote hands...I do tend to have some kind of device at arms reach at all times, and my phone is always on...but it's rare to be full on unless Office365 has gone tits or someone has done something stupid.
It was a lot more full on 20 years ago when techies were expected to be present, whether there was something happening or not...but these days, not so much...I think the pandemic gave a lot companies pause for thought and they realised that IT guys were a lot more valuable than they thought they were because I'm sure it became quickly apparent that well rested techies that were treated well and looked after did an amazing job during that time, and the put upon knackered ones didn't...I stepped in for a lot of fired techies at the start of the pandemic when we went into the first lock down because they just couldn't perform for various reasons. My existing clients were all fine because I'd had them setup for remote work for years at that point anyway...they just rarely used it...it was quite interesting actually because I had loads of "panic stations" meetings that were setup to discuss moving businesses to remote working only to tell them "it's cool, we're already setup, it's X icon on your desktop on your laptop and the 2FA app on your phone, just go home, connect to your wifi, connect to the VPN, it's all good"...a lot of the companies I stepped into (which came through recommendations from clients I already had) were massively underprepared...they had the kit and capability, but none of the setup and deployment had been done and their previous sysadmins had no idea how to set it up.
In my opinion, dyfunction in tech began when tech became a "job". In my early days in tech, it wasn't really seen as a job as such by the people doing the work. The people working in tech roles were engineers long before they were paid to do it...it was just what they did. You didn't choose a career in tech, you just wanted to be somewhere that allowed you to get your hands on new tech on a regular basis (and the old stuff being turfed out)...because you were a fucking nerd and it was all about the tech, the fact you got paid a lot of money for it was inconsequential, it was just a byproduct, still is for me I rarely think about it and I never worry about being paid "market rates" for stuff, all that matter to me is whether the project is interesting, I've done plenty of jobs for free on that basis alone. These days people enter the tech industry as a career choice because it's financially appealing, it's not always directly linked to the goals of the business and therefore theoretically lower stakes, the barrier to entry is quite low or they simply retrained from another profession that was once their passion but it wore off when reality kicked in and work just became work and tech was just an easy choice. There are just as many passionate people in tech now as there have ever been, but they are greatly outnumbered by the people that are just "doing a job"...their motivation is completely different and these are the people that need to be managed and monitored. Because they only do as they are told, they not thinking about the next steps. Whereas the "fucking nerds" are always pushing ahead, they want the new stuff, they want to break new ground and constantly improve things not only for the benefit of the business but because they can.
Tech has become a lot less dysfunctional (although to some degree it is still dysfunctional) since the pandemic because some of us were able to build up a level of trust that previously just didn't exist. There is a spectrum of different types of experience working in the tech industry that is based quite heavily on skill base, common sense and understanding. If you aren't anything special skill wise, the CEO of the company you work for has no common sense and the people around you don't understand what you're doing...you're going to be at the shitty end of the spectrum...if you're highly skilled, your CEO has common sense and the people around you understand what you do, you're going to be at the decent end of the spectrum.
Totally agree. Whether it's 47 days or 47 centuries it doesn't matter in terms of the work load, it's just as automatic depending on who issues the certs. The only thing I do is login on a box from time to time to check in and see if the certs are renewing on the expected dates to see if there has been any shift...or in the case of LetsEncrypt to see I've been silently moved to a different CA (because this can sometimes bring about compatibility issues with some devices that don't update their CA roots very often...isn't that right...AMAZON TVs???).
Aside from that, I'm usually checking in on servers periodically anyway...and if I have to do a manual renewal, it's like 30 seconds out of my way...it's nothing...I think people rolling out super long term certs are trying to avoid looking like fuckwits come renewal time.
Let's Encrypt obsoleted their "legacy" automatic renewals recently. I guess if updating certificates is your full time job this is not a PITA.
"Just automate it using a magic script that you have no idea how it works and it might go away at any time because you need to move to the latest hip mechanism for automatic renewal for the children" isn't an answer that fills me with warm cozy happy feelings.
"I have no idea when my certs renew or how long they're valid for:"
That's a fail: You should, as they will cost you, eventually. This "47 days" is a preliminary act towards that. Also it effectively bans private people using SSL as it's too much of a hassle. How convinient. Naturally self-signed sertificates are also banned, you may not have SSL for free.
Funny thing is that top level certificates are valid for 10 years, only *your* certificate isn't.
I'm not up to speed on the technology, but the incident comes to mind in "Harry Potter and the Prisoner of Azkaban" where access control by password was strictly enforced and updated within Hogwarts School... and then one student copied out the list of passwords for the rest of the year - and lost it. Luckily I suppose, a senior teacher found the copy. Passwords were changed, and I think I remember that that particular student wasn't told what any of the new passwords are.
If one certificate can be installed on your server and then stolen by people up to no good - then twelve certificates for the rest of the year can be installed on your server and then stolen by people up to not good.
I bet the next rule change they make is that no entity will be permitted to renew a certificate if its been hacked, and doesn't have a clean statement of health from Mandiant.
I'm going to reconfigure my internal sub-CA to start giving out certificates that expire in 2030 (which is when my sub-CA cert expires.) Between now and 2030, I'll generate a new root CA and give it a 50 year lifetime and my new sub-CA will get a 25 year lifetime and just one more round of certificates and i'll be retired before they expire again.
The browser/CA forum are solving the wrong problem. We all know this, but it doesn't help that they don't have the power or ability to solve the underlying problem.
p.s. Are they going to shorten the CA certificate lifetimes as well? What about the DNSSEC root key lifetimes?
I've been self CA signing internal certs for 800 days for at least 5 years(prior to that it was for 10 years at a time), never had a complaint that a browser didn't like it(assuming they installed the CA to trust). Probably 95% of my certs are like that, only a few externally signed. No fancy automation (too many different kinds of systems and processes) other than decent alerting to know when they expire.
Overall seems pretty pointless to me. History shows that attackers maintain access to networks and systems for extended periods (months) on average so they can just grab the newer certs as they get installed.
Not sure about the quantum angle that makes no sense. The cert is about identification not about securing data transmission.
Nah, I think internal CAs will be fine...though I've always questioned the wisdom of having an internal CA...at some point it has to be handed over to someone and that someone isn't always competent with managing a CA, and by the time you find that out, you're years in and they're harder to sack.
"The cert is about identification not about securing data transmission"
That depends on the type of cert and how it is implemented and also how it is issued, you can issue client certs from a CA for use with VPNs etc...although I haven't seen this sort of thing for yeeeeears. It was quite common back in the RRAS days...the dark days...with RADIUS and Cisco PIX firewalls...man I need a scotch now and a corner to cry in...you've stirred up emotions in me man. I thought I kept it bottled up and buried.
*flashback intensifies*
It wasn't my fault. I was a junior...with a year of experience, I was only 19, and they fired the IT manager, I was alone. There was no handover or docs. Please let me go home, I'm tired...I've been here 15 hours. :'C
*rocking in a corner arms crossed weeping*
15 hours? You weenie. You aren't a serious IT person until you've put a mark in every 15 minute box for a whole day on a timesheet...and then had to have your manager explain to Payroll and Accounting that yes, you did, in fact, work from 00:00 Thursday until 23:59:59 Thursday, in addition to 16 hours on Wednesday and 7 hours on Friday.
Certainly don't have to use an internal CA. If I left and nobody did anything worst case is certs expire and they either issue new certs through the CA, or issue certs another way, or go back to device self-signed certs, or just leave them expired. Most things with the certs on them don't care if the certs expire(internal websites, management interfaces etc), and the user can just choose to ignore the expired cert and continue using the service.
I've been using internal CAs since around 2007 just to make my experience cleaner, not prompted by every self signed internal device in different browsers over time. One of my managers pointed out that's a nice way to improve security to know the certs are trusted and that's true though security wasn't the reason for doing it.
Bit of both perhaps...but it really isn't that big a deal renewing your certs following or during one of the things in that list.
It boggles the mind that it's 2025 and the sheer number of people posting here are clearly the kind of people that shit themselves when a cert renewal is coming up. It's not a fucking arcane tech skill. Yes, it sounds complicated...cryptography, keys, ciphers and a lot of other scary terminology, but it's fucking text files man. 99% of the time, all you need to do is put the text files in the right place...that's all it is...that's all it has ever been.
Windows makes a whole song and dance about certificate management with it's overblown tools, wizards etc...but behind the scenes...text files man...fucking text files.
It's three lines in an apache / nginx config pointing to a pair or maybe trio of text files...depending on how you want to handle the chain.
It's highly likely that you will only ever need to update the cert on the regular, you probably won't have to update the chain or the key every 47 days. So it's literally one text file. ONE!
ONE FUCKING TEXT FILE that happens to have a .pem extension.
The panic, rage and cynicism here is unbelievable. I'm at the point where I don't believe that many actual active techies post here anymore. It's all miserable old twats, juniors and charlatans.
Renewing a cert is something I can do on a whim at 4am when I'm barely awake...it's that easy...and yet I can charge a fortune for it because the vast majority of IT folks out there shit themselves dry when a renewal comes up because they're scared stiff...it's fucking wild.
And some aren't. APC PDUs used to require pkcs15 certs. Some HP arrays require a very long list of subjectAltName entries for controller clusters' certificates. Graylog requires pkcs7 certs. Some systems are smart enough to contruct their certificate chain from CA, sub-CA, sub-CA, and device certificates. Others require the full chain in a single file. Some require the certificates to be copied to the device blind, and to followed by a reboot.
Tell me you only handle basic systems without telling me you only handle basic systems.
It gets to be more "fun" when you're dealing with things like large RDS setups, where each published app needs to signed with the new cert and republished, on each and every RDS server. Coupled with the RD client on users machines occasionally crapping the bed, losing its feed and needing to be re-setup. So now rather than a small percentage of clients needing manual intervention each year, you've got that happening every ~6 weeks.
"Renewing a cert is something I can do on a whim at 4am when I'm barely awake...it's that easy...and yet I can charge a fortune for it because the vast majority of IT folks out there shit themselves dry when a renewal comes up because they're scared stiff...it's fucking wild."
If you have a single web server running IIS, that's hardly a drain on your valuable time sunshine.
We have twenty IIS installs, all with SSL links, some wildcards, some with designated URL. We have Apache, Nginx and Tomcat on production systems as well. Systems that if they are down, even for a few seconds at the wrong time, people can die. We run WiFi controllers that require bag attributes, and phone servers that need custom cert installs as well. Not to mention the encrypted links to various government agencies that are a nightmare in and of themselves.
Changing the entire system so Apple can update an iPhone for a marketing bullet point thrills me not.
This will simply force people to take other less secure avenues to fill in the gaps. Us included.
Another thing that poster doesn't seem to be taking into account, or perhaps hasn't worked in such an environment, is when you have large financial systems with swaths of consumer systems, network appliances and endpoint services in a particular app/data flow that are making use of multiple SSL configurations, including in many cases complex two-way SSL. In those scenarios, you need to coordinate tightly with everyone involved in order to get the renewed certificates placed on their systems otherwise you may end up running into all sorts of different issues relating to certificate trust issues.
It's already quite a cumbersome undertaking when you are dealing with let's say 200 plus different certs, being renewed on a yearly basis.
Windows is a pain to do manually at least. I haven't done it many times but for example installing a cert for IIS or installing a cert on Active directory for LDAPS. Using openssl to convert the cert/key/CA to a pkcs12 keystore, then importing it in the right place and switching over to it. It can be quite a process, and scary for first timers, or if you haven't done it in a while.
With IIS I recall when I install a new cert that has the same name, it installs fine, but then you go to the IIS config to tell it which cert you want to use, and the drop down menu is duplicated, one entry for each cert, so if you have 5 certs in there with the same common name(even if say 3 are expired), it will show 5 options and you sort of have to guess which one to use. Maybe the newest is on top or bottom I am not sure. It would be nice if it showed the cert dates or whether or not a cert was expired at least.
LDAPS certs you have to put it in the special place and LDAPS picks it up automatically and starts using it. But it's still a funky process.
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority
I have since modified the process to not create the cert request from the server itself and just do everything end-to-end on a Linux-based CA, the import the resulting keystore at the end, much easier/faster.
LDAPS for Domain Controllers: Never manually. GPO to make the fetch it automatically from the AD Issuing CA, done. They renew automatically too. Same goes for "Domain Controller Certificate", which is NOT necessarily the same as the one for LDAPS/Kerberos. The root CA does not have to be Windows.
For IIS: In certlm, the propierties of the certificate allows to set a "friendly name", I add there the domain, possibly what is for, and most importantly: The date it was created in iso8601.
The method to force-import the complete pk7 package, with a key you generated: You should be careful to keep the same private key for the server, and every server a different private key. And have a working CRL there.
Another thing: As soon as you use auth on the switch/WLAN with 801 certs, you really want to have a windows PKI and all windows clients and users fetching their cert automatically. This way all AD-joined devices are allowed automatically. Unless you revoke the cert of course.
perhaps for larger scale orgs. I don't do windows stuff, mainly Linux. No company I've ever worked for had windows staff manage SSL anything(they were always fine with all self signed device certs/default certs - or in the case of anything using LDAP they just used plaintext LDAP not LDAPS), they've never had CAs. Maybe it's easy to set that stuff up I'm not sure.
Only reason I did it like that is because if I didn't do it, it wouldn't get done. I'm not about to touch anything with domain policies/GPO or anything.
> I'm not about to touch anything with domain policies/GPO or anything.
Specially if you inherit old GPOs which still have Office 2010 or 2003 settings. When the Management tools on newer server bork and you have to use a old server with older OS to analyze what is all in there. Recently cleaned up an AD where only ONE Server 2012 (non R2) was able to show all GPOs... Cleanup / nuke the offending GPOs, ADMX cleanup rigerously, and then reinstate those few ADMX actually needed for newer office and done. Sounds easy, hm? I understand why you keep you hands of. Powerful, can run a lot of havoc, and too many fiddle in the Default* policies...
"99% of the time, all you need to do is put the text files in the right place...that's all it is...that's all it has ever been."
That's proper BS. It applies if you use it only for a web server, but once it's used for other things, it's not that simple at all.
Also, as usual, the last 1% is 99% of the work, so whole argument is irrelevant.
Keeping a key safe is easy. Renewal is complicated, even if there's enough tooling on top to make it seem simple.
The scenario I see being the easiest is a social engineering or vulnerability attack that puts ownership of a domain name into question. The faster certs expire, the less time there is for a resolution process to complete.
having a system where any trusted CA can sign for any site is crazy
americans can sign for indian government sites is frankly crazy
these are commercial entities telling foreign governments what they can run on their servers
the only way out of this is DNS
that way the entity who controls the DNS can control the certificate from soup to nuts not just which CA they choose
That was ruled out as it would require browsers to implement their own DNS resolution libraries, which they all now do.
Also something about how DNSSEC supports weaker cryptography than TLS, and therefore they require that you return a (no need to be signed) DNS record to prove something or other before you can get a certificate that they like.
It does seem to me that this is one of those "we already made the decision, why would we reconsider how applicable it is to the modern web?" situations.
Even the Big guys can't get this right;
MacOS can't re-install certain versions without hacking around an expired certificate in the low level startup:
We all saw Google blow up their Chromecasts last month;
https://www.theregister.com/2025/03/13/google_chromecast_fix/
And Firefox baked a certificate in that killed all extensions by accident;
https://support.mozilla.org/en-US/kb/root-certificate-expiration
And these jokers wanna go through this every six weeks?
Ignore the certificate costs (Many will let you rekey for free); This sounds like a lot of planned obsolescence being built in to the whole system, which I suspect is the real benefit to Apple, Google, et all...
If nothing else, it's going to be a lot of users learning to hit the ignore and continue button on certificate errors...
I don't think I am, I don't dread certificate renewals like a lot of so called sysadmins do. If you run a relatively tight ship, It's a trivial task that takes minutes at worst. It can be automated to the point where you really don't have to think about it all you need to do is check in on it every now and then...which should happen as part of your routine maintenance anyway...seriously, what is the big deal? Who hurt you? What was the bit length of the certificate they touched you with?
Not at all...I run a setup that has thousands of certificates deployed to it on a load balanced proxy setup, it's a single sign on service that allows the use of custom domains for a particular industry...I just did it properly and I know what I'm doing...I've probably renewed and deployed more certificates than you can imagine.
Nice try.
If you're infrastructure is complicated you fucked it up and cut the wrong corners. You should work on that, remove some complexity. Might save your business $$$...if you don't, one day someone might show up and make you look like an idiot and take your job...you're gifting them an easy ride...reducing complexity is low hanging fruit...I know, it's what I do for a living...save hundreds of thousands of pounds for tens of thousands of pounds and most of the time, it is just a complexity reduction exercise...I never compromise performance or functionality, I just simplify...
It doesn't matter if a system has to support 2 users in one location or 2 million users in thousands of locations. Complexity shouldn't increase with scale. If it does, your solution *sucks*. Why would anyone with any common sense design a system that gets harder to manage and more complicated as it scales up?
Classic ivory tower commandment. The cloud types pushing for it, hoping that everyone switches to cloud crap, even when they don't need it, so that they can rent the service for more, rather than utilize what they previously bought.
I'm waiting for the real estate market to catch up, buy a home, pay off the mortgage and then rent the home anyway. Oh wait, they have that with HOA's.
I remember the PIA it was when the US DoD switched to SSL/TLS only, no more plaintext HTTP for anything. I was information assurance by then, so I'd get the requests to forward to DISA to get the certificates. Had to give the entire LAN/WAN shop a class in SSL/TLS and certificates, due to alias vs hostname largely. And it'd just be a breeze for doing a few hundred webservers - if one's counting a tornado as a breeze.
This will turn into a massive goat screw over time, mark my words. It's not as if the server's going to ask for a replacement for an expiring certificate direct from the CA.
This post has been deleted by its author
The first SaaS company I worked at two decades ago, used tons of certs, 99% server certs (I remember I had a special portal with Verisign so I could issue my own certs), and some client certs even. Cert problems were almost constant.
One time I recall reporting a cert issue, I found the source and was going to fix it, one of the higher tier support people was confused he didn't see any issues. So I went to his desk and walked him through the workflow.
His browser popped up the expired cert warning and he clicked through it without even realizing it. I said THAT'S THE PROBLEM THERE. Took him a few seconds to realize what he had done. It was pretty funny, so used to errors you just click through without thinking about it.
Colleges can barely tie their shoes... their websites and other services relying on commercial certificates will start falling over on those dates as the dates reduce.
This just makes more work for people who have a lot of other things to take care of. Universities are less of an issue - they tend to have more staff and more experienced staff.
But either way, it's going to be grim.
I work for a University. It's going to suck. Data Security have decided that an internal CA is not good enough for them, and we need commercial (because they also demand OV certs) certs for every bit of network kit. It's not so much the cost - Universities have a bulk buying power through JISC and GEANT - it's the headache of dozens of appliances that *cannot* have their certs renewed in an automated manner. Eventually everything will get updated to play nice, but I humbly predict that will happen after the certpocalypse these changes will bring. We're already paying extra for some commercial code to make certbot and the Citrix frontend play nice together and it's going to get worse. The contractors will be laughing.
yes, there are always problems when they update the wifi certificate. some devices see and accept the new certificate and just keep going. Some devices that miss the weekend update just sputter and go off line. most likely to be smartphones, but laptops and desktops using wifi also have trouble reconnecting sometimes. so once a year will be every 6 weeks going forward?
My experience of various universities is that their Computer Science departments (used to) have brilliant sysadmins running secure top-notch Unix-like systems, whilst the central university IT services have M$ systems run by monkeys. But increasingly university manglement has sacked the CS IT people and imposed their incompetent M$ systems on everybody. Worst bit is that this is purportedly done in the name of "data security".
I have just found out about Putt's Law: "Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand."
This is getting to the level where security is not the real reason. It is a money making scheme. Enforcing dependencies, constant monthly pay. And you will have to pray those automatic certificate mechanisms work reliable. It works surprisingly well within Active Directory with its own two-step CA since Server 2000, no problem with such short lived certificated, but that is in YOUR hand. (Note that I EXCLUDE Azure/Entra here!)
But such short lived certificates are a problem for AD as well: Client certificate running out so fast that a vacation is enough to knock a laptop out. Computer was off for two month? Sorry, you will have to bring it in PHYSICALLY, since VPN/AD/Whatever certificate of user AND computer are no longer valid any more, and remote sessions are denied to untrusted devices and users. A server need to be turned on after two month to get some migration-missed-data-or-scripts back? Forget it. And I've seen server examples with 2+ years off, resurrected either by "VM was forgotten to be deleted" or from backup...
But that makes zero sense as a counter-argument. Ignoring the fact it's all OSS and LE is a non-profit, which has legal implications - hell, it was originally sponsored by Moz and the EFF. There's zero margin to be had, if you're right and they do that, where's the money coming from? There might be arguments about the usefulness and other things, but you can't find a profit motive from your scenario.
Even a "it's the NSA and aliens" argument is more rational than a profit argument in the scenario. And there's zero basis for that.
We're not going back to that world, because it's dumb, everybody knew it was dumb but allowed it to go on anyway - if we can't have easy cert issuance for free, it'll be opportunistic encryption or something and it'll be moot.
Yes it's about money and competitive advantage. They "think" this makes it harder for newcomers or businesses that can't afford the extra overhead, heap on as much burden as possible. The small guys cost increases don't get absorbed so much and its assumed they'll mess up more. Also, the security guys at the bigs are specialised and less likely to think about the impact on other departments. This will actually not work for long, people will produce solutions to help automate both honest and dishonest use of certs. The bigs are money machines at their heart everything is oriented to financial results released to the market.
No it's not, I support a lot of small guys and I already rotate certs once a month at all of them, it's just good practice...I won't support a business that insists on long term certs without some kind of solid justification / actual business case for...it's monumentally stupid. Certificate management is not a dark art, it's not difficult...it takes 2 minutes out of your day to do manually and it can be automated very reliably...a 10 year certificate is a very expensive way to get out of a 2 minute job.
It's very easy to get into a position where you have boxes setup with so much long term stuff that you might only login to once a year...this is dangerous practice because it can lead to you not checking in on your infrastructure regularly enough.
A quick 2 minute certificate check once a month can save your balls...because it forces you to login to a server to check and while you're there, you can have a quick look at everything else...if you're smart, you'll have a summary pop up when you login to give you an idea of the activity on that box...and you might as well check for security updates while you're there.
We're techies, we're in the business of maintaining and repairing things...we're not in the business of building boxes that nobody touches for a decade.
I prefer preventative maintenance rather than break / fix...it's way less stressful and my clients can see I'm "on it" constantly...they don't have to wake up in cold sweats running "what if" scenarios in their heads. They will know when maintenance is occurring, they will have seen me do it dozens of times before, and they won't have to have loads of "what if / how much downtime" meetings to brace for impact.
Yeah the AD situation kinda sucks, it's already a thing before shorter certs come into play.
It's definitely a problem that doesn't need to exist though, you can fix it...I think a lot of people experienced this over the pandemic with badly configured VPNs...even though you could access company resources, the VPN DNS setup would probably prevent proper communication with the AD...I made a lot of money during the pandemic fixing this for people.
There are three very simple fixes, assuming your company kit has a VPN that connects before login...
1) You tunnel DNS to your internal DNS servers...probably the best solution, but sometimes the hardest if your sysadmin has sat on his thumbs for years and never touched the endpoint hardware since they took over and they have actively ducked and dived to avoid it because they don't know how to manage it.
2) You deploy a hosts file with the appropriate records in to facilitate basic communication with the AD, even if you don't tunnel DNS, so even if a laptop has been off for months, when you boot it, it sorts itself out before a user logs in.
3) You hard code some static routes and DNS entries in your client side VPN config (where possible).
There is also a less technical option...
4) You make it part of the holiday booking process to hand in their kit before they go and take it out of circulation to ensure they have to fire it up in the office when they pick it up after they get back.
You went a bit off-topic to my starting posting, since my complain predicts what happens if AD-certificates get such s short lifetime... :D
> You deploy a hosts file
This suggestion is nuts. We are past 1990, just wrong. Attaching the right DNS suffix to the adapter and/or add the right DNS Server to that adapter manually is the way to fix this. Sometimes I wish I could just add a resolv.conf to Windows (or something similar), but that is not wanted "by design decision".
> You hard code some static routes and DNS entries in your client side VPN config
Yep, some VPNs insist on doing it that way. Normally should be pushed to the client from the VPN server, but that is not the reality for way too many VPN clients. Even from well known brands.
> You make it part of the holiday booking process
This is actually the standard for many with A-AD-Entra (whats it name tomorrow?) hybrid scenarios. Goes wacko way too often. With the "pure entra ID login, no AD" even more.
I'm with you in that hosts files are usually a bad idea. Resolv.conf though, I'd say is equally annoying.
On Windows - just use Powershell to set DNS parameters if you really must set them manually.
On a fair bit of modern Unix editing resolv.conf is a huge pain to be avoided as it can easily get overwritten by a local resolver.
I would far prefer to use the DNS server to set it. If you can't do it via an AD based DNS server because of a VPN, do it on a downstream DNS server.
I realise there will be some VPN and networking combinations that make this difficult; VPNs are much better than they used to be but still not exactly perfect.
I'd also note that when I spent the effort to do DNS properly on my home network rather than using public DNS, and assigned my work laptop the work domain for resolution by default (everything else on my personal domain) the VPN client on restore from hibernation went from spending 5-10 seconds thinking about if it could see the remote endpoint to being available instantly.
The internet is owned by the mob, this is a racketeering scheme. "The Industry decides how long certificates are valid, and you dumb (l)user has to swallow what we invent".
How about companies decide themselves about their certificates, a small firm with a "Hello World" website doesn't have the same security requirements as an online banking site.
People will have to upgrade, replace and are confronted with increased complexity to "make" them use and buy the services sold by the same industry that sets the norms.
These IT-industry practices should make every sane person puke.
But of course, every consultant and journalist will be cheering, since stupidity rules the world atm.
"No seriously though, even though I think the argument for is moot and possibly a little bit silly, does anybody even pay for certs any more? I thought most people were just using LE these days, at work it's all we use, let alone for home gaming."
Oh yes ? And what will happen when LE is down and rid of ? You'll have to automate in another way with another service etc ...
As was said many times, a lot of manual work for no real security added value (the renewal is sure to be hacked).
I read about expired certs all the time, but I don't think I've ever read about a compromised cert. So why the sledgehammer?
I don't really accept the 'money' argument. Ignoring LE's free certs, CA's will simply let you continue to purchase multi year certs at the same cost, but issue short term certs and give free renewals up to expiration, just as they do now if you want a cert longer than a year.
So why this push from the big companies? Are compromised certs really a thing?
But they only indicate that a piece of software was signed by a valid cert, having the code signing certs expire doesn't do anything for the binaries, they' will still be valid as long as the signing cert isn't revoked. if its only expired, (from my last use of one) the appplication will still load and run normally.
The security risks in deploying automation and renewing so often are surely greater than the risk of a compromised certificate. As you say, you almost never hear about such things and it would be rather big news for a major site. Even the rare compromise I've heard of has been at the intermediate/CA level where they have to cancel and then re-issue certs anyhow.
I see chaos ahead but at least people will be safe not being able to use those sites! The biggest screw ups will come from businesses just protecting sites for staff use. People will say they can't work, managers will run round like headless chickens shouting at IT. This happens already, now it can happen more. How safe are certificates anyway? Seems like if you have a fake id you can get one? I guess they make man in the middle hard? Feel free to educate me!
Let's walk through what was happening at my previous job.
1) We have servers that we want web access to, but not for the entire internet.
2) LE only works if you are open to the internet.
3) ???
What I did when I came in was open the servers up to the internet long enough for LE to do its thing.
We were on Amazon, however, so I figured out how to switch over to their certs.
But suppose we weren't.
---
Yes, in theory cert compromise is a fundamental problem. But in practice, I don't think we've had ten articles about it happening here in the last 20 years.
In the mean time, EVERY one of the bigs pushing this has had more bugs than that every year--most every month.
Try fighting fires that are actually burning.
HTTP challenge is not the only method of authenticating to Lets Encrypt. If you control DNS you can put a token in there that does the same job. You’ll want to be able to automate your DNS as the token changes each time.
But webservers are generally easy, you can install things like certbot to do this for you. The pain is with ‘appliances’ where the only access is through a GUI.
You can also do the renewal on a proxy, or some other box which can control the DNS or website. You then set up a system to copy those certificates into production.
I have certbot running on 2 servers but generating certificates for dozens. There may be a delay of a day or two with my current scheduling, but renewals happen before the last one expires anyway.
This is a bad choice because it's simply too short to be usable.
It places a massive burden on IT teams to do the replacement. Not everything can be automated at present - I can't use LetsEncrypt on my switches, or my SSLVPN device, or my firewalls. I have application servers that use Apache Tomcat, which is a much more manual process.
So the end result will be that when this short timescale fails - because someone is off ill at the wrong time - we will end up training our colleagues to ignore the certificate warning so that they can still do their work.
That is a far, far worse outcome than any issues with highjacked certificates. Highjacked certificates may also require DNS access to use effectively, or other access to the target's systems. But this ends up training users to behave in an insecure manner.
I hope that they reverse course on this.
Reverse course ? - not a chance in Hades. The obvious* solution is for everyone to move absolutely everything into the cloud and never have to worry our little heads about such complicated problems again because our personal terminals will be updated automagically every time they sniff a connection.
* to those running the clouds
All of the web (http) servers can go on let's encrypt so they are being renewed automatically.
All the rest need their certs installing manually. That one component where you have to uninstall it and then reinstall to update the cert. The tomcat containers that want the cert dropped into a folder with a specific name. Some want a pfx, some want the CA chain and the cert separately some want it all bundled together. Binary certs, base64 certs.
Glad I'm not the one responsible for that any more.
For a big co with lots of people, nice modern network stacks and the like I'm sure this is nice and easy.
For an SME with one man doing the network and a fragmented network stack (because cheapest is the answer), then things get very sketchy. While you might be able to auto update IIS, try a still supported but older Sonicwall firewall or MDaemon mailserver etc. I'm sure there are ways to automate all of them too, but it's then down to that one man, trying to find out how, and made even more fun if your clients don't want you using free certs.
10 days... is mad.
[switch female computer space station announcer voice on]
Hi! I am IT department. I can tell why 47, 120 and 398 are good. The first thing: We don't wait until the last day to renew a certificate and do it several days ahead. Usually two weeks to six weeks are good choice for extra time, depending on how long the certificate should be valid. This allows planning the renewal at the same day of each month, the same day every three month or same day each year.
For a certificate which is exactly 365 days, the renewal process moves, on average, 14 or more days each year. If you have exactly 31 days the renewal process moves a few days each month.
Many certificate-forgotten-renewal issues happen due to that moving date for such certificates, since renewal HAS to be done BEFORE it is over. Preferably at least a week to catch problems with the new certificate and be able to use the old certificate longer while troubleshooting the new certificate.
Thank you for reading this IT department announcement.
[switch female computer space station announcer voice off]
How often are people rooting webservers and stealing the certificate private keys for nefarious purposes?
I'm sure it's happened to somebody somewhere, but I can't recall a single instance that I've read of heard of.
And there are a million places where TLS certificate replacement can't be easily automated (network admins know what I'm talking about). There are plenty of places where, frankly, it just doesn't matter if the connection is secure, but you put a certificate in place anyway just to shut the browser up. Checking the toner level of the printer down the hall: who cares? The power distribution switch on a network that's locked down so tight it's half a notch from completely airgapped? If they've dug in so deep that they've rooted that sucker then they almost certainly got there by compromising something far more critical.
This is dumber than companies making users change their passwords every 47 days. Busywork for no benefit, more things to break, more associated consequences, and all for no measurable security gain.
If you're that worried about your servers being hacked, nothing is stopping you from regenerating your certificates every day if that makes you happy. If your company is so sloppy that you're letting critical certificates go 50 years between renewals, then forcing you to change them more often just chews up resources that would be better spent in a million better places.
Every single person behind this decision should be banned from the industry and have the words "Idiot nanny" indelibly tattooed on their foreheads.
Trouble is, all the big guys will happily go along with it.
So basically it will be smaller outfits - who will then suffer from users being told that your "mom&pop webshop is insecure and the user should find someone who isn't going to steal everything including the kitchen sink from them". And who are the users going to listen to ? It isn't going to be you, because in their minds (thanks to the messaging from the people pushing this) you are unreliable and nothing you say counts.
Just look at how the big boys have stitched up email - they just make changes and the rest of the world either follows suit or gets disconnected. OK, some fo the changes make sense, some of them don't.
Web servers - not so much. I imagine the big commercial boys will have sorted this properly by 2029 even for those with little experience, and open source won't be too painful either. Personally the last time I used certificates for public facing servers was the mid to late 00s and it was less painful each subsequent renewal as processes improved.
I have to say that whilst work are (generally) OK with certificates and administration in general we have had production systems go down due to failed monitoring and renewal processes. There's really no excuse for this, but with changes of this magnitude the onus is really on the operating system vendors to make this bullet proof in most conceivable situations, and it clearly isn't.
I foresee problems with SSO, which from the looks of things is affected in the same way. It's already enough of an issue integrating with third party companies with various degrees of technical competence.
To give you an idea of how horrific some companies are : one company had secure socket authentication issues because the time on many of their systems was out by at least an hour. This was not a small company, and they absolutely refused to consider mid 90s technology (well into the 10s) to fix their estate. Whilst my personal response would be 'fix your systems, you idiots' the business generated necessitated some unwelcome workarounds instead.
Hopefully with notice this move will be OK - the relatively swift move to TLS 1.1, then 1.2 or better was actually quite well received by customers. I was glad to be able to get rid of some horrific legacy devices that didn't actually even support TLS 1.0 correctly.
Automated certificate maintenance on embedded devices is a bigger deal, and I've already seen a recent example where a manufacturer is refusing to support devices because (cynical assumption) 'we want to make more money, that's why, buy our new kit'. I will put money on certain customers having to upgrade in a couple of years despite the device being perfectly capable to run current standards, and then a year later being told 'the device you upgraded to doesn't support automated certificate update, our management software can't handle it (because we choose not to), buy another device'.
Oh, and the management software, which used to be free, is now subscription based and vastly more expensive because Numbers Must Go Up and damn everyone else.
So, whilst the certificate cost may be minimal, the software and device upgrades certainly aren't.
47-day TLS certs are lunacy, but the real crime’s been years of browser makers bullying industry with cipher suite demands.
Embedded systems, PLCs, RTUs, medical devices, run on stable standards, not Google’s whims. With tiny memory and no internet, they can’t chase TLS 1.3 or new ciphers.
Now we’re stuck rigging routers to transcode HTTPS or falling back to HTTP just to access a control panel?
This isn’t security; it’s big tech torching critical infrastructure.
Fork the browser or watch industry burn.
C/AB have made this decision with no consideration for end users. This needs an organised push back, they need to be forced into a reversal (somehow!)
Look, SSL mechanisms can be automated for most new web environemnts - fair enough. Especially for HTTP/DCV validation. Dns validation could be a bit trickier - i'm not sure I want or trust anything automated messing with my DNS zones.
What about the other uses for SSL? IMAP etc, SMTP, CCTV, BMS, older embedded systems, some of them delibarately blocked from internet for secirity/common-sense reasons.
And it gets worse - DCV verified certs will come down to what? 10 days? That's ridiculous. The instability that will cause with so many things needing to be renewed and reconfigured/reloaded.. automatically? Really? and nothing will go wrong and break a server?
What a terrible decision.
If you're running either AD based DNS or a mixed BIND/KEA infrastructure there is *already* something automated messing with DNS zones through the use of either DDNS or other updates. Not sure that's a problem - it's reasonably locked down, there's a fair bit of logging, and the security control is quite granular.
Not particularly worried about SMTP/IMAP etc either, by the time 2029 rolls round the products can be updated or upgraded to support certificate renewal.
Embedded systems, older systems, non mostly directly Internet connected systems fair point!
BMS was a new acronym for me, I can imagine on a vaguely related note all sorts of IoT definitely not supporting the infrastructure. So many more devices to be ewasted, or to more probably have internal CAs set up.
It's going to be a whole set of manual hassle, or buying new systems to handle it. Out of interest I went looking at the state of motherboard BMC which I haven't had to touch professionally for some time, and personally for cost related reasons is limited to second hand ex corporate ebay hardware. The hardware I have here supports manual certificate updates, but modern server motherboards do now appear to support centralised management which could resolve this, and I really do mean modern. Looking at recent Supermicro BMC manuals it appears at first glance that products from late 2024 include the necessary management, but it's not apparently obvious that anything older does.
Start planning for substantial hardware refreshes in the next few years!
By BMS;
I intended - various arrangements of tech comprising Building Management/Monitoring Systems. Alarms, Temerature, Access control - Sometimes (though not usually integrated CCTV)
This will create a shit-ton of work, lots of things sre not webservers, able to be sensibly connected to the wider internet, or easily replaced (expense and/or complexity).
C/AB and to an extent PCI comiance schemes are becoming too driven by commercial interstes and essentially unfit for purpose.
So what happens when your entire country is off the net for 10 days? It has happened to Tonga and boats try to cut subsea cables frequently.
Has anyone ever seen an actual example of the shorter certs solving a security problem or is it just wisdom handed down by the church of BOFH for ulterior motives?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
