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

111–120 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#111

Post by whatevaa »

9dev wrote: post #88
FuriouslyAdrift wrote: post #79

Earlier quoted context omitted.

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?

Fronting a switch management interface with haproxy? Are you sure that is a good idea?

Re: SSL certificate requirements are becoming obnoxious

#112

Post by znpy »

stego-tech wrote: post #80
pelagicAustral wrote: post #47

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

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

Don't take this as a snarky comment, but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in.

> PKI isn’t a solved problem.

PKI is largely a solved issue nowadays. Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need.

It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess).

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

Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance.

Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology.

Re: SSL certificate requirements are becoming obnoxious

#113

Post by holoduke »

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…

Older Android 7 devices are not supported with letsencrypt. For us still 20% of our userbase. We went for a paid subscription with zerossl.

Re: SSL certificate requirements are becoming obnoxious

#114

Post by tialaramex »

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

This is what fascinated me too.

FWIW the idea of inspecting the certificate "for typos" or similar doesn't make sense. What you're getting from the CA wasn't really the certificate but the act of signing it, which they've already done. Except in some very niche situations your certificate is always already publicly available when you receive it, what you've got back is in some sense a courtesy copy. So it's too late to "approve" this document or not, the thing worth approving already happened.

Also the issuing CA was required by the rules to have done a whole bunch of automated checks far beyond what a human would reasonably do by hand. They're going to have checked your public keys don't have any of a set of undesirable mathematical properties (especially for RSA keys) for example and don't match various "known bad" keys. Can you do better? With good tooling yeah, by hand, not a chance.

But then beyond this, modern "SSL certificates" are just really boring. They're 10% boilerplate 90% random numbers. It's like tasking a child with keeping a tally of what colour cars they saw. "Another red one? Wow".

Re: SSL certificate requirements are becoming obnoxious

#115

Post by 9dev »

darkwater wrote: post #110
9dev wrote: post #68

Earlier quoted context omitted.

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…

> 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. I completely agree with you but you would be astonished by how many companies, even s…

> […] that restarting/redeploying/renewing as less as possible is the best way to go instead of fixing the root issue that makes restarting/redeploying/renewing a pain in the ass.

I mean… There's a tradeoff to be sure. I also have a list of things that could be solved properly, but can't justify the time expense to doing so compared to repeating the shortcut every so often.

It's like that expensive espresso machine I've been drooling over for years—I can go out and grab a lot of great coffee at a barista shop before the machine would have saved me money.

But in this particular instance, sure; once you factor the operational risk in, proper automation often is a no-brainer.

Re: SSL certificate requirements are becoming obnoxious

#116

Post by greyface- »

Avamander wrote: post #31
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…

The same the exact IP addresses or ASNs of existing validation origins are not public, neither will any future ones be. It makes it a bit harder to coordinate an attack against this infrastructure.

It's trivial for an attacker to learn the validation origins by triggering validations of their own servers while watching the logs. Secrecy confers no advantage here.

Re: SSL certificate requirements are becoming obnoxious

#117

Post by tyzoid »

btown wrote: post #52
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…

Sure, there is an argument about slippery slopes here. But the thing about the adage of "if you slowly boil a frog..." ( https://en.wikipedia.org/wiki/Boiling_frog ) is that not only is the biological metaphor completely false, it also ignores the fact that there can be real thresholds that can change behavior. Imagine you run an old-school media company who's come into possession of a beloved website with decades of…

Pretty much any legacy system can have a modern reverse proxy in front of it. If the legacy application can't handler certs sanely, use the reverse proxy for terminating TLS.

Re: SSL certificate requirements are becoming obnoxious

#118

Post by commandlinefan »

I would be ok with all of this if it meant anything. My computer has 151 trusted Certificate Authorities installed on it, including heavy hitters in the CA industry such as TUBITAK, Telia and Sectigo. As a user, I have no idea what sort of actual verification went into verifying the certificates that the site I'm visiting is presenting.

Re: SSL certificate requirements are becoming obnoxious

#119

Post by jraph »

throw0101a wrote: post #102
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…

> The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors. There are environments and devices where automation is not possible: not everything that needs a cert is a Linux server, or a system where you can run your own code. (I initially got ACME/LE working on a previous job's F5s because it was RH underneath and so could get Dehydrate working (only needs…

In these setups, the issue already exists: an appliance would have to renew its SSL certificate when it expires. I believe ssl certificates should already not be used anywhere they can't be renewed.

Re: SSL certificate requirements are becoming obnoxious

#120

Post by [deleted] »

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…

[deleted]
Post reply on HN