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

81–90 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#81

Post by luma »

pelagicAustral wrote: post #47
Intermernet wrote: post #38

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

Re: SSL certificate requirements are becoming obnoxious

#82

Post by pferde »

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.

That could be an argument against automating anything, ever.

The solution is just like with any other automation - document it.

Re: SSL certificate requirements are becoming obnoxious

#83

Post by ameliaquining »

everforward wrote: post #72
auguzanellato wrote: post #43

Earlier quoted context omitted.

Do you really need more oversight on renewals than a simple success/failure notification? For new certificate you can keep the existing amount of human oversight in place so nothing changes on that front.

Yes, because you want to know what certificates you're issuing. You could be automatically issuing and deploying certs on a system where the actual app was decommissioned. It's probably mostly a risk for legacy systems where the app gets killed, but the hardware stays live and potentially unpatched and is now vulnerable to a hacker taking it over. With manual renewals, the cert either wouldn't get renewed and would b…

This is what Certificate Transparency is for. If you want to know what publicly trusted certificates are being issued for whatever domains are of interest to you, that's how you find out. It has the important advantage of always working no matter how heterogeneous your stack is; the clients that request certificates do not need to be connected to any particular notification system.

Re: SSL certificate requirements are becoming obnoxious

#84

Post by cr3ative »

mholt wrote: post #48

First line: > I am responsible for approving SSL certificates for my company. And that is exactly what the requirements are intending to prevent. Automation is the way. The system is working!

Right. This unfortunately reads like a human process has been set up where automation should have been set up, and now that hand is being forced.

The hand-waving away of certbot/ACME at the very end of the article only really goes to show that it hasn't been looked in to properly for whatever reason.

Re: SSL certificate requirements are becoming obnoxious

#85

Post by trenchpilgrim »

o_m wrote: post #60
Intermernet wrote: post #38

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…

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.

There are paid ACME services - basically LE with paid support.

Re: SSL certificate requirements are becoming obnoxious

#86

Post by 9dev »

birdman3131 wrote: post #32
jraph wrote: 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…

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.

Re: SSL certificate requirements are becoming obnoxious

#87

Post by ozim »

Jeslijar wrote: post #14
gdbsjjdn wrote: post #3

I understand OP's frustration, but the alternate view is that mandating better practices is a forcing function for businesses that otherwise don't give a shit about users or their privacy or security. For all the annoyance of SOC2 audits, it sure does make my manager actually spend time and money on following the rules. Without any kind of external pressure I (as a security-minded engineer) would struggle to convince…

Why is a month's expiration better than a year or two years? Why wouldn't you go with a week or a day? isn't that better than a whole month? Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over? Maybe the problem isn't that certi…

There was an attempt doing it differently by CRL but it turns out certificate revoking is not feasible in practice on web scale.

Now they are doing next plausible solution. Seems like 47 days is something they found out by let’s encrypt experience estimating load by current renewals but that last part I am just imagining.

Re: SSL certificate requirements are becoming obnoxious

#88

Post by 9dev »

FuriouslyAdrift wrote: post #79
dale_glass wrote: post #10

I believe the low maximum lifetimes are becoming a thing because revocation failed. CRLs become gigantic and impractical at the sizes of the modern internet, and OCSP has privacy issues. And there's the issue of applications never checking for revocation at all. So the obvious solution was just to make cert lifetimes really short. No gigantic CRLs, no reaching out to the registrar for every connection. All the requir…

Because of all my internal systems that use certs to connect (switches, routers, iot, etc) that have manual only interfaces (most are tftp), I have had to go back to just running my own CA infrastructure and only using public CAs for non-corporate or mixed audience sites/services. It's really annoying because I have to carve outs for browsers and other software that refuse to connect to things with unverifiable certs…

Why is fronting these systems with a central haproxy with TLS termination or similar not an option?

Re: SSL certificate requirements are becoming obnoxious

#89

Post by stackskipton »

skylurk wrote: post #9
sunneyx wrote: post #4

[flagged]

Not for long. https://blog.nginx.org/blog/native-support-for-acme-protocol

CaddyServer is still easier since declaring HTTPS for a site will trigger let's encrypt. Nginx requires module loading and other things.

Re: SSL certificate requirements are becoming obnoxious

#90

Post by yladiz »

zimpenfish wrote: post #77
yladiz wrote: post #29

Earlier quoted context omitted.

I'm not sure if you're arguing in good faith, but assuming you are, it should be pretty self-evident why you wouldn't generate the certificate dynamically each request: it would take too much time to do so, and so every request would be substantially slower, probably as slow as using Tor, since you would need to ask for the certificate from a central authority. In general it's all about balance, 1 month isn't necessa…

> since you would need to ask for the certificate from a central authority Could it work that your long-term certificate (90 days, whatever) gives you the ability to sign ephemeral certificates (much like, e.g. LetsEncrypt signs your 90 day certificate)? That saves calling out to a central authority for each request.

Without knowing the technical details too much: Maybe, although I don’t think it would make much difference in my argument, since it would still add too much time to the request. Likely less, but still noticeable.
Post reply on HN