Live data from Hacker News

SSL certificate requirements are becoming obnoxious

chrislockard.net

201–210 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#201

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…

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 meeting.

Are certificates truly explicitly defined to be infrastructure that requires change approval? If not, perhaps more careful interpretation of the regulations could allow for improved automation and security outcomes.

Re: SSL certificate requirements are becoming obnoxious

#202
post #200

I've only put maybe 2 seconds of thought into this so it is probably stupid, but why don't we have an alternative that does not require third party certificate authorities? For example why not allow an organization to have its own self-signed certificate authority, and allow it to publish its self-signed root certificate through DNS, and make browsers accept that root for use with that domain? I see two objections of…

This is called DANE. I don’t know if I missed an implied /s in your message.

You overlooked the need for DNSSEC, so another PKI with his own quirks, and somehow less reliable than CAs.

Re: SSL certificate requirements are becoming obnoxious

#203

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…

> Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year I run a couple of low-stakes websites just for fun and manually updating certificates takes me about 10 minutes a year, and most of that is remembering how to generate the csr. Setting up an automated process gains me nothing except additional points of failure. Ratcheting the expiration down to 47…

I run a few low-stakes hobby things, and LE cert automation took the "once a year or so figure out how to do this because I haven't done it in a year and I should write it down but when I'm done I just go to the pub instead" to "", which was a nice change. Now I only have to interact with it when I add a new vhost to the web server, and that's just run a command to do so.

Re: SSL certificate requirements are becoming obnoxious

#204

Earlier quoted context omitted.

> Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year I run a couple of low-stakes websites just for fun and manually updating certificates takes me about 10 minutes a year, and most of that is remembering how to generate the csr. Setting up an automated process gains me nothing except additional points of failure. Ratcheting the expiration down to 47…

What's frankly ridiculous is that the big softwares like Nginx and Apache don't deal with this on their own. I've been letting Caddy (my http host of choice) deal with TLS for me for _ages_ now. I don't have to think about anything, I don't have to setup automation. I just... configure my caddy to host my website on https://my.domain.com and it just fetches the TLS for me, renews it when necessary, and uses it as nec…

Nginx just added support for acme iirc.

Re: SSL certificate requirements are becoming obnoxious

#205

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 think part of this can be explained by the fact that in many corporations, code and everything supporting it, like development time, developer quality, infrastructure maintenance and software architecture aren't seen as investiment but sunk cost that needs to be reduced ad infinitum to appease shareholders, so they throw human suffering and business risk at it to make it look good in the next quarterly report.

Re: SSL certificate requirements are becoming obnoxious

#206
post #86

Earlier quoted context omitted.

One of the arguments to be made is that while " automation reduces the possible human errors." it also reduces the amount of human oversight as well.

Oversight over… what exactly? TLS certificates don't need human oversight. If you want to see which certificates have been issued for your domains, set up certificate transparency monitoring. But thank goodness we're past paying people for comparing certificate checksums.

Schrödinger's certificates are so mundane they don't need human oversight, but are so precious they need to be renewed every 47 days

Re: SSL certificate requirements are becoming obnoxious

#207

Earlier quoted context omitted.

I don't know what a replacement for the web would look like. But it seems apparent to me that it will have to work over HTTP/QUIC, and TCP port 443. Which prompts the obvious question ...

As a friendly reminder, SRV records exist and are great at fixing that magic port syndrome (unless you were hinting at the infinite corporate firewall appliances, for which I have no magic fix)

Right. Egress on anything other than tcp/443 is probably a non-starter for any new protocol.

The question I was alluding to is: if it's HTTP-ish over tcp/443, wouldn't it still be the web anyway?

But thinking about it more, the server could easily select a protocol based on the first chunk of the client request. And the example of RTP suggests that maybe even TCP would be optional.

Re: SSL certificate requirements are becoming obnoxious

#208
post #194

Earlier quoted context omitted.

How would you propose things should work instead?

The idea would be the ability for a certificate to accept multiple signatures, making it more of a "web-of-trust" system. So you still have your LetsEncrypt certificate, but maybe augmented by another signature from an similar authority located in another country, or some other reputable organization that has your best interests in mind. Maybe there are problems with that, but I never really understood the limit of a…

Does this solve any problem that isn't solved equally well by just acquiring multiple separate certificates? I guess it would make your service highly available in case of revocation, but unexpected revocations are rare enough that almost everyone is willing to run the risk of a brief outage in case one occurs.

Re: SSL certificate requirements are becoming obnoxious

#209
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.

Generally agree, that we shouldn’t jump on conclusions, but experts in my own field are doing bad things mainly because of lack of knowledge. With the lack of will as a very close contender for the top position. “The lack of possibility” is the exception.

When I argued here that Linux is still pain to maintain on my laptops, it wasn’t because it’s not possible. I just didn’t have enough willpower.

People who jumped on me because of this were still idiots, because they thought that their even less knowledge (what were the error messages, my exact setup, etc) can be helpful for me, but still it would be wrong to state that I was unsuccessful because it’s not possible, or I had full knowledge back then.

Especially now, that I’m running Linux full time.

For example, I’m quite sure that you can solve this problem with a proxy, no matter what’s behind it. Maybe it’s infeasible, because you would need a custom proxy implementation, but it’s definitely possible.

Re: SSL certificate requirements are becoming obnoxious

#210

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…

A $100 fee makes it costly to burn and churn new accounts. So it's a spam filter.

Forcing developers to stay engages pushes out feature complete software but also pushes out unmaintained software.

An app store is an inherently higher cost distribution method. The operating systems are gratis so development is cross subsidized from app store royalties. They have an incentive to host more paid apps, especially micro-transaction apps that trick kids into spending thousands of dollars off mom's credit card. Of course they've banned or are going to ban alternative channels so you can't choose to self-distribute.

Post reply on HN