Live data from Hacker News

SSL certificate requirements are becoming obnoxious

chrislockard.net

101–110 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#101
Nobody has yet mentioned how certificates induce and support churn.

In 2025 it's not possible to create an app and release it into the world and have it work for years or decades, as was once the case.

If your "developer certificate" for app stores and ad-hoc distribution is valid for a year, then every year you must pay a "developer program fee" to remain a participant. You need to renew that cert, and you need to recompile a new version within a year. Which means you must maintain a development environment and tools on an ongoing basis for an app that may be feature- and operationally-complete.

All this is completely unnecessary except when it comes to reinforcing hegemony of app-store monopolists.

Re: SSL certificate requirements are becoming obnoxious

#102
post #15

The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors. Many things need to be run and automated when running stuff, I don't understand what makes SSL certificates special in this. For a hobbyist, setting up certbot or acme.sh is pretty much fire and forget. For more complex settings well… you already have this complexity to manage and therefore the peopl…

> The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors.

There are environments and devices where automation is not possible: not everything that needs a cert is a Linux server, or a system where you can run your own code. (I initially got ACME/LE working on a previous job's F5s because it was RH underneath and so could get Dehydrate working (only needs bash, cURL, OpenSSL); not all appliances even allow that).

I'm afraid that with the 47-day mandate we'll see the return of self-signed certs, and folks will be trained to "just accept it the first time".

Re: SSL certificate requirements are becoming obnoxious

#103
post #11

Earlier quoted context omitted.

>Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer. ??? All my servers use certbot and it works fine. There's also no shortage of SaaS/PaaS that offer free ssl with their service, and presumably they've got that automated as well.

Out of about three dozen places I need a certificate, I believe one recently added support for ACME. Tell me you aren't in enterprise IT without telling me you aren't in enterprise IT. ;) It may help you to understand that it is not an assumption any given product even supports HTTPS well in the first place, and a lot of vendors look at you weird when you express that you intend to enable it. One piece of software re…

Your perspective may be just as narrow, albeit from the other end of the spectrum. Huge heaps of things do work just fine with ACME now, or support being fronted by a reverse proxy which does.

Plus, how would you ever get enterprise tool vendors to add support if not for customers pestering them with support requests because manual certificate renewal has gotten too painful?

> I do not think PKI will survive the 47 day change. […] In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.

Maybe PKI will die… or you will. Progress doesn't treat dinosaurs too well usually.

Re: SSL certificate requirements are becoming obnoxious

#104
post #69

Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year, and that's only because I forget the steps required to setup auto-renewal. I pay nothing, I spend a tiny amount of time dealing with it, and it works brilliantly. I'm not sure why many people are still dealing with legacy manual certificate renewal. Maybe some regulatory requirements? I even have a w…

I really hate the HTTPS requirement that Google unilaterally mandated for everyone. Just wait until SSL is used to prevent us from publishing anything. Your ID will have to be on file and be compliant. We've gone from really simple tools to tools that could easily be used to ensnare us and rid us of our rights. Encryption doesn't necessarily mean privacy. It can also mean control.

it mainly means control these days. ive made SSL then later TLS requirements for web browsers and we had fights on this sort of stuff.

yeah encryption is needed. but then you need authentication. and then, if authentication is controlled by corporations you're f'd.

instead youd want identities to be distributed and owned by everyone. many trust models have been developed and other than raw UI problems (hi gpg/pgp) its really not a terrible UX.

Re: SSL certificate requirements are becoming obnoxious

#105

Earlier quoted context omitted.

I work for government and I can tell you the guys working infrastructure are still paying for shitty SSL certificates every year, in most cases for infrastructure that doesn't even see the light of day (internal), and the reason for that is none other that not knowing any better, and being unable to get their head out of their asses for enough time to learn something novel and implement it in their workflow. So yeah,…

In our defense, it’s because we’re expected to give everything a cert but often have no say on the security and cryptography capabilities of what’s brought onto the network in the first place, nevermind the manpower and time to build such an automated solution internally. Execs bringing in MFPs that don’t support TLS, PLCs that require SHA-1, routers with a packet buffer measured in single-digit integers but with a J…

It is solved but devices you are talking about refuse to get on board with the fix so here we are.

Also, I used to do IT, I get it but what do you think the fix here is? You could also run your own CA that you push to all the devices and then you can cut certificates as long as you want.

Re: SSL certificate requirements are becoming obnoxious

#106
post #81

Earlier quoted context omitted.

I work for government and I can tell you the guys working infrastructure are still paying for shitty SSL certificates every year, in most cases for infrastructure that doesn't even see the light of day (internal), and the reason for that is none other that not knowing any better, and being unable to get their head out of their asses for enough time to learn something novel and implement it in their workflow. So yeah,…

Alternatively, those people are dealing with legacy systems that are pathologically resistant to cert automation (looking SQUARELY AT YOU vmware) and elect for the longest lasting certs they can get their hands on to minimize the disruption. It’s generally best to assume experts in other fields are doing things for good reasons, and if you don’t understand the reason it might be something other than them being dumb.

Yeah OK, touché, I was over the top... I just need my cup of coffee...

Re: SSL certificate requirements are becoming obnoxious

#107
What is obnoxious is that certificate transparency logs mean that you now have to effectively centrally register any new domain you put online. That means you instantly see a whole load of traffic to your domain from bots, scrapers, beg bounty scanners etc. Any new site has to be designed to handle that baseline of traffic.

I understand the point of CTL's and it's necessary given that every browser and device is configured to trust CA's that you wouldn't actually trust. It's had awful side effects for people who want to host low traffic sites, or fly under the radar for whatever reason.

Re: SSL certificate requirements are becoming obnoxious

#108
post #7

I think the author has missed the point of the 47 day expiry. It is short enough to force teams to automate the process. You're not supposed to be human-actioning something every month. But yes, it'll be a huge headache for teams that stick their head in the sand and think, "We don't need to automate this, it's just 6 months". As the window decreases to 3 months it'll be even more frustrating, and then will come a br…

Is there a different implementation timeline that you think would adequately address the legitimate concerns of orgs relying on legacy and manual processes? My model is that beyond a baseline of a couple years (which were already granted), adding more time doesn't help, because these orgs will always procrastinate until the last minute on anything that doesn't seem to management like an obvious immediate priority. I think the CA/B Forum does understand this and that they're significantly inconveniencing a lot of people, but it has to happen sometime, and part of the purpose of the push for automation is to ensure that the inevitable future tightenings of security requirements won't require most orgs to do anything.

Re: SSL certificate requirements are becoming obnoxious

#109
I actually don’t have a problem with the SSL changes as they specifically pertain to http servers – it’s largely a dived problem with automated solutions compatible with all the major players on most fronts.

But certs and every other context have become neigh impossible except in enterprise settings with your own CA and cert servers. From things like printers and network appliances to entirely non-http applications like VPN (StrongSwan and OpenVPN both have/support TLS with signed SSL certs, but place very different constraints on how those work in practice and what identities are supported, how or if wildcards work, etc).

Very little attention has been paid to non-general purpose and non-http contexts as things currently stand.

Re: SSL certificate requirements are becoming obnoxious

#110
post #68

Earlier quoted context omitted.

I just recently had a executive level manager ask if we could get a 100 year cert for our ERP as the hassle of cert management and the massive cost of missing a renewal made it worth it. He said six figures for the price would be fine. This is an instance where business needs and technology have gotten really out of alignment.

How on earth would that make more sense than properly setting up ACME and forgetting about the problem for the next hundred years?? If your bespoke ERP system is really so hostile toward cert changes, put it behind a proper reverse proxy with modern TLS features and self-sign a certificate for a hundred years, and be done with it. It'll take about fifteen minutes of time, and executive level won't ever have to concer…

> How on earth would that make more sense than properly setting up ACME and forgetting about the problem for the next hundred years?? If your bespoke ERP system is really so hostile toward cert changes, put it behind a proper reverse proxy with modern TLS features and self-sign a certificate for a hundred years, and be done with it.

I completely agree with you but you would be astonished by how many companies, even small/medium companies that uses recent technologies and are otherwise pretty lean, still think that restarting/redeploying/renewing as less as possible is the best way to go instead of fixing the root issue that makes restarting/redeploying/renewing a pain in the ass.

Post reply on HN