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

61–70 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#61

Post by jraph »

linsomniac wrote: post #44
azeemba wrote: post #5

I think a large enough org that needs many different certificates should have an internally-trusted CA. That would then allow the org to decide their own policy for all their internal facing certificates. Then you only have to follow the stricter rules for only the public facing certs.

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 its configuration by itself, which I don't like)

Re: SSL certificate requirements are becoming obnoxious

#62

Post by FuriouslyAdrift »

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.

No better way to create errors at scale than automation ;-)

Re: SSL certificate requirements are becoming obnoxious

#63

Post by layer8 »

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…

CRLs don’t have to be large, since they only need to list revoked certificates that also haven’t expired yet. Using sub-CAs, you can limit the maximum size any single CRL could possibly have. I’m probably missing something, but for SSL certificates on the public internet I don’t really see the issue. Where is the list of such compromised non-expired certificates that is so gigantic?

Re: SSL certificate requirements are becoming obnoxious

#64

Post by stego-tech »

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…

As someone on the other side of the fence who lives primarily in IT land, this is far from a solved problem. Not every device supports SSH for copying certs across the network, some devices have arbitrary requirements for the certs themselves (like timelines, lack of SANs, specific cryptography requirements, etc), and signing things internally (so that they’re only valid within the intranet, not on the internet) doesn’t work with LE at present.

So unless you’re part of the folks fine heavily curating (or jailbreaking) devices to make the above possible, PKI is hardly a solved problem. If anything it remains a nightmare for orgs of all sizes. Even in BigCo at a major SV company, we had a dedicated team to manage PKI for internal certificates - complete with review board, justification documents, etc - and that still only bought us a manual process with a lead time of 72 hours for a cert.

That said, it is measurably improved and I do think ACME/certbot/LE is on the right track here. Instead of constant bureaucratic revisioning of rules and standards documents, I believe the solution here is a sort of modern Wireguard-esque implementation of PKI and an associated certification program for vendors and devices. “Here’s the cert standard you have to accept, here’s the tool to automatically request and pin a certificate, here’s how that tool is configured for internal vs external PKI, and here’s the internal tooling standards projects that want to sign internal certs have to follow.”

Basically an AD CA-alike for SMB and Enterprise both. Saves me time having to get into the nitty gritty of why some new printer/IoT/PLC doesn’t support a cert, and improves the posture of the wider industry.

Re: SSL certificate requirements are becoming obnoxious

#65

Post by [deleted] »

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…

[deleted]

Re: SSL certificate requirements are becoming obnoxious

#66

Post by CamouflagedKiwi »

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've worked with a major financial institution (let's just say that you'd definitely recognise the name) in a past job, and while I couldn't really see exactly what was going on with the certs they issued, I'm sure it was a pretty manual process given our observations of things changing then reverting again later. I don't think regulation was really the issue though, just bad old processes.

I wonder what they will do with the shorter validity periods. They aren't required to comply in the same way; it's not a great look not to but I can't believe the processes will scale (for them or their customers) to renewing an order of magnitude more frequently.

Re: SSL certificate requirements are becoming obnoxious

#67

Post by elp »

b112 wrote: post #12

I've spent 15+ minutes searching, and the digicert (linked to in the article), and other cert providers all reference a vote on "Multi-Perspective Issuance Corroboration (MPIC)". Everywhere I've read, one "must validate domain control using multiple independent network perspectives". EG, multiple points on the internet, for DNS validation. Yet there is not one place I can find a very specific "this is what this means…

Unless I'm completely misunderstanding things Letsencrypt has been doing this since 2020 https://letsencrypt.org/2020/02/19/multi-perspective-validat...

I.e they check from multiple network locations in case an attacker has messed with network routing in some way. This is reasonable and imposes no extra load on the domain needing the certificate all the extra work falls on the CA, and if Letsencrypt can get this right there is no major reason why "Joe's garage certs" can't do the same thing.

This is outrage porn.

Re: SSL certificate requirements are becoming obnoxious

#68

Post by 9dev »

FuriouslyAdrift wrote: post #50
Jeslijar wrote: post #14

Earlier quoted context omitted.

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…

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 concern themselves with something as mundane as TLS certificates again.

Re: SSL certificate requirements are becoming obnoxious

#69

Post by echelon »

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

Re: SSL certificate requirements are becoming obnoxious

#70

Post by hombre_fatal »

belval wrote: post #54
allan_s wrote: post #28

Earlier quoted context omitted.

I think it's all about change management a whole month put you in the "if you don't have the resource to automate it, it's still doable by a human, not enough to crush somebody, but still enough to make the option , let's automate fully something to consider" hence why it's better than a week or a day (it's too much pressure for small companies) better than hours/minutes/secondes (it means you go from 1 year to 'now…

> it creates pressure (oh my.... not the scary yearly certificate renewal, i remember last year we broke something, we i don't remember what...) Ah yes, let's make a terrible workflow to externally force companies who can't be arsed to document their processes to do things properly, at the expense of everyone else.

But it's a decent trade-off and you're using sarcasm in place of fleshing out your claim.

Monthly expiration is a simple way to force you to automate something. Everyone benefits from automating it, too.

Post reply on HN