Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSL certificate requirements are becoming obnoxious

chrislockard.net

Post reply on HN
Print view View original

231–240 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#231

Post by linsomniac »

jraph wrote: post #61
linsomniac wrote: post #44

Earlier quoted context omitted.

We make extensive use of self-signed certificates internally on our infrastructure, and we used to manually manage year-long certs. A few months ago I built "LessEncrypt", which is a dead simple ACME-inspired system for handing out certs without requiring hijacking the HTTP port or doing DNS updates. Been running it on ~200 hosts for a few months now and it's been fantastic to have the certs manage themselves. https:…

Why or in which cases is opening a dedicated port better than publishing challenges under some /.well-known path using the standard HTTP port? (You say hijacking the HTTP port, but I don't let the ACME client take over 80/443, I make my reverse proxy point the expected path to a folder the ACME client writes to, I'm not asking for a comparison with a setup where the acme client takes over the reverse proxy and edits…

The case for it is where it's not easy to plop a file in a .well-known path on port 80/443. If you have a reverse proxy that is easy to set up to publish that, that makes it easier. I guess I could have used different wording, I do consider making the .well-known available a subset of hijacking the port, but can see why it would be confusing. ACME setup can still be trickier to set up, but is definitely a good solution if it fits in your environment.

Re: SSL certificate requirements are becoming obnoxious

#232

Post by Loudergood »

FuriouslyAdrift wrote: post #155
zoeysmithe wrote: post #78

Earlier quoted context omitted.

Yep this. This is just "we have so much technical debt, our square pegs should fit into all round holes!" Business culture devaluing security is the root of this and I hope people see the above example of everything that's wrong with how some technology companies operate, and "just throw money at the problem because security in an annoying cost center" is super bad leadership. I'm going to guess this guy also have an…

IT serves business needs... not the other way around. If anything, cloud services and mobile device access has made securing anything just about impossible.

Classic case of business not understanding that it doesn't just need access to the data, it needs secure access to the data.

Re: SSL certificate requirements are becoming obnoxious

#233

Post by syncsynchalt »

ericpauley wrote: post #201
TrueDuality wrote: post #196

Earlier quoted context omitted.

Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates. - Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal) - All infrastructure changes need to have the commands executed and con…

It seems like the core problem here is that certificates are considered part of infrastructure, and further that they're part of infrastructure that requires approval! Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time. Further, changes to data can't universally require approval, otherwise every CRUD operation would require a committee m…

> Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time.

In these sort of environments, they do not.

We're talking about environments where it is forbidden to make _any_ change of any kind without a CCB ticket. Short cert lifetimes are fundamentally at odds with this. Luckily these systems often aren't public and don't need public certs, but there's a slice of them that do.

Re: SSL certificate requirements are becoming obnoxious

#234

Post by Loudergood »

stblack wrote: post #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 r…

Yup, I bought and paid for a simple Android game that my kids could play together while we were waiting for thing.

New phone and suddenly I can't install it from Google Play anymore simply because the developer hasn't updated it in awhile. Not that it needs to be updated. I've since repurchased it from itch.io and it runs fine, but that's not unusual for lots of good old software.

Re: SSL certificate requirements are becoming obnoxious

#235

Post by patrakov »

aitchnyu wrote: post #92
o_m wrote: post #60

Earlier quoted context omitted.

The older I get the more skeptical I get to free services that run on others servers. They have a bunch of expenses and you are getting it for free. You are not the customer. I rather pay for a service than gamble on some free service that might be shut down at any time, or that might have malicious intents.

Whats a LetsEncrypt competitor which has convenient automated renewal?

ZeroSSL - they provide Sectigo certificates under the hood. Works well with Dehydrated.

Re: SSL certificate requirements are becoming obnoxious

#237

Post by syncsynchalt »

m-p-3 wrote: post #236

It's cumbersome for a reason, and I believe it will lead to better tooling and automation.

The better tooling and automation already exists, it's really all over but the shouting. The pain comes from supporting vendor equipment that's already on its way to the dustbin. Vendors that fired their entire engineering group half a decade ago and have no way to respond, but the equipment will still be in production for another 20 years.

There are many solutions (reverse proxies, private CAs, literally hiring a guy to manually update certs on each bit of equipment every 35 days), some of them are painful, but it's not worth handicapping the security of the entire public web for them.

Re: SSL certificate requirements are becoming obnoxious

#238

Post by FuriouslyAdrift »

9dev wrote: post #223
FuriouslyAdrift wrote: post #143

Earlier quoted context omitted.

Yet more infra that must now be managed and a point of failure. No thank you.

Well. That, or maintaining bespoke PKI and internal CA, along with manually renewing certificates with ever-shortened expiration periods as demanded by browsers. Pick your poison.

Windows infra so certificate services is already baked in for 802.1x, etc.

Re: SSL certificate requirements are becoming obnoxious

#239

Post by syncsynchalt »

rini17 wrote: post #37
xnorswap wrote: 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…

When it's automated we're back at square one: after few years it breaks and nobody will have any idea where the acme scripts are or how to debug them.

And if something silently breaks, would you rather the breakage is noticed within 47 days, or 398 days?

Even your unrelated question is another argument for shortened certificate lifetimes. :-)

Re: SSL certificate requirements are becoming obnoxious

#240

Post by syncsynchalt »

dark-star wrote: post #13

> I am responsible for approving SSL certificates for my company What does this even mean? Does he check the certificates for typos, or that they have the correct security algorithm or something? I'm pretty sure such an "approval" could be replaced by an automatic security scanner or even a small shall script

There are environments where it's required that _every_ environmental change has an associated CCB ticket. In that kind of environment, yes, every new cert is attached to a ticket that the board has to review and approve.

Yes, it's insane, but it sure makes fault analysis easier when the environment is that locked down and documented.

Post reply on HN