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

71–80 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#71

Post by Andoryuuta »

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…

Semi-related: Firefox 142 was released a few days ago and is now using CRLite[0], which apparently only needs ~300kB a day for for the revocation lists in their new clubcard data-structure[1].

[0]: https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

[1]: https://github.com/mozilla/clubcard

Re: SSL certificate requirements are becoming obnoxious

#72

Post by everforward »

auguzanellato wrote: post #43
birdman3131 wrote: post #32

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.

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 become naturally invalid or the notification that the cert expired would prompt someone to finish the cleanup.

Re: SSL certificate requirements are becoming obnoxious

#73

Post by johannes1234321 »

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…

The exact time probably has no "best" but from past times: I have seen so many places where multi-year certificates were used and people forgot about them, till some service suddenly stopped working and then people having to figure out how to replace that cert.

A short cycle ensures either automation or keeping memory fresh.

Automation of course can also be forgotten and break, but it's at least somewhere written down in some form (code) rather than personal memory of a long gone employee who previously uploaded certs to some CA website for signing manually etc

Re: SSL certificate requirements are becoming obnoxious

#74

Post by sam_lowry_ »

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.

I already had this with the certbot on Debian that was running perfectly for 5-6 years by that time.

Re: SSL certificate requirements are becoming obnoxious

#75

Post by jraph »

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.

With you in general, but in this specific case, the whole thing seems healthy:

- Many companies (including competitors) are sponsoring LE, so the funding should be quite robust

- These companies are probably winning from the web being more secure, so the incentives are aligned with you (contrary to say, a company that offers something free but want to sink you under ads)

- the vendor lock-in is very weak. The day LE goes awry, you can move to another CA pretty painlessly

There are CAs supporting ACME that provide paid services as well.

Re: SSL certificate requirements are becoming obnoxious

#76

Post by evilduck »

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…

For all but one of my personal use cases, Tailscale + Caddy have even automated away the setup steps and autorenewal of SSL with LetsEncrypt. Just toggle on the SSL features with `tailscale cert`, maybe point Caddy at the Tailscale socket file depending on your user setup, then point an upstream at the correct hostname and you're done.

Re: SSL certificate requirements are becoming obnoxious

#77

Post by zimpenfish »

yladiz wrote: post #29
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'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.

Re: SSL certificate requirements are becoming obnoxious

#78

Post by zoeysmithe »

9dev wrote: post #68
FuriouslyAdrift wrote: post #50

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…

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 MFA exception on his account and a 7 character password because "it just works! It just makes sense, nerds!" I've worked with these kinds of execs all my career and they are absolutely the problem here.

Re: SSL certificate requirements are becoming obnoxious

#79

Post by FuriouslyAdrift »

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 and adding my CA to some software or devices is a either a pain or impossible.

It's created a hodge podge of systems and policies and made our security posture full of holes. Back when we just did a fully delegated digicert wildcard (big expense) on a 3 or 5 year expiration, it was easy to manage. Now, I've got execs in other depts asking about crazy long expirations because of the hassle.

Re: SSL certificate requirements are becoming obnoxious

#80

Post by stego-tech »

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,…

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 Java web GUI, all of these horrors and more are why it’s such a shitshow even today.

Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses. Believe me, I’ve been fighting this battle internally my entire career and I hate it. I hate the shitty state of PKI today, and how the sole focus seems to be public-facing web services instead of, y’know, the other 90% of a network’s devices and resources.

PKI isn’t a solved problem.

Post reply on HN