Live data from Hacker News

SSL certificate requirements are becoming obnoxious

chrislockard.net

141–150 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#141

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…

But that has nothing to do with certificates as such and everything to do with app store policies. Certificates don't induce churn - app stores do.

Re: SSL certificate requirements are becoming obnoxious

#142
post #136
post #128

Earlier quoted context omitted.

Because then you have plain HTTP running over your network. The issue here (I presume) is not how to secure access over the Internet, but within an internal network. Plenty of people leave these devices without encrypted connections, because they are in a "secure network", but you should never rely on such a thing.

Nothing stops you from using a self-signed certificate with a ridiculous expiration period for HTTPS between the reverse proxy and the device in question.

Except browsers and other software that are becoming hard-coded to block access to such devices.

We used to use Firefox solely for internal problem devices with IP and subnet exclusions but even that is becoming difficult.

Re: SSL certificate requirements are becoming obnoxious

#143
post #122

Earlier quoted context omitted.

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

Yes. If we're talking about handling TLS termination and putting an IP behind a sensible hostname, I don't see what's wrong about using a reverse proxy. Note that this does not imply making it accessible on the internet.

Yet more infra that must now be managed and a point of failure. No thank you.

Re: SSL certificate requirements are becoming obnoxious

#144
post #112

Earlier quoted context omitted.

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

> but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters. > 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…

Interjecting into this back-and-forth real quick.

* Yes, I have experience with Vault. I have deployed it internally, used it, loathed it, and shelved it. It’s entirely too cumbersome for basic PKI and secrets management in non-programmatic environments, which is the bulk of enterprise and business IT in my experience.

* You’re right, the organization is the problem. Let me just take that enlightened statement to my leadership and get my ass fired for insubordination, again, because I have literally tried this before with that outcome. Just because I know better doesn’t mean the org has to respect that knowledge or expertise. Meritocracies aren’t real.

* The reason I don’t solve my own PKI issues with Caddy in my homelab is because that’s an irrelevant skill to my actual day job, which - see the point above - doesn’t actually respect the skills and knowledge of the engineers doing the work, only the opinions of the C-suite and whatever Gartner report they’re foisting upon the board. Hence why we have outdated equipment on outdated technologies that don’t meet modern guidelines, which is most enterprises today. Outside of the tech world, you’re dealing with comparable dinosaurs (no relation) who see neither the value or the need for such slick, simplified solutions, especially when they prevent politicians inside the org from pulling crap.

I’ve been in these trenches for fifteen years. I’ve worked in small businesses, MSPs, school campuses, non-profits, major enterprises, manufacturing concerns, and a household name on par with FAANG. Nobody had this solved, anywhere, except for the non-profit and a software company that both went all-in on AD CA early-on and threw anything that couldn’t use a cert from there off the network.

This is why I storm into the comments on blogs like these to champion their cause.

PKI sucks ass, and I’m tired of letting DevOps people claim otherwise because of Let’s Encrypt and ACME.

Re: SSL certificate requirements are becoming obnoxious

#145

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…

And yet, I am a bit worried that now, most of the web depends on LetsEncrypt. That's a single point of failure. Sure, they are "good guys", really, but remember that Google used to be "good guys" too. And this is a US-based organization, dependent on US rules, which is not so bad, but alternatives would be nice.

And yes, there are alternatives, but everything is made so that LetsEncrypt is the only reasonable choice.

First, if you are not using https, you get shunned by every major web browser, you don't get the latest features, even those that has nothing to do with encryption (ex: brotli compression), downloads get blocked, etc... So you need https, good thing LetsEncrypt make it so easy, so you use LetsEncrypt.

Because of the way LetsEncrypt verification works, you get short-term certificates, ok, fine. Other CAs do things differently, making it short-term certificates impractical, so your certificates last longer. But now, browsers are changing their requirements to only short-term certificate, but it is not a problem, just switch to LetsEncrypt, and it is free too.

Also, X.509 certificates, which is the basis of https (incl. TLS, HTTP/3, ...) only supports a single signature, so I guess it is LetsEncrypt and nothing else.

Re: SSL certificate requirements are becoming obnoxious

#146

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…

Just thinking out loud here: an ACME DNS-01 challenge requires a specific DNS TXT record to be set on _acme-challenge. as a way of verifying ownership. Currently this is a periodic check every 45 or 90 or 365 days or whatever, which is what everyone's talking about. Why not encode that TXT record value into the CA-signed certificate metadata? And then at runtime, when a browser requests the page, the browser can veri…

I think the problem with this idea is not security (as you point out, the status quo isn't really better), but availability. It's not all that uncommon for poorly designed middleboxes to block TXT records, since they're not needed for day-to-day web browsing and such.

Also, I don't see how that last paragraph follows; is your argument just that client-side DNS poisoning is an attack not worth defending against?

Also, there's maybe not much value in solving this for DNS-01 if you don't also solve it for the other, more commonly used challenge types.

Re: SSL certificate requirements are becoming obnoxious

#147
post #69

Earlier quoted context omitted.

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.

Certs are free. All you need is a domain name and letsencrypt.

Slippery slope. Who controls the domain name system? Who controls how certs are handled by browsers and which ones are trusted?

All of these things we take for granted can change. You're watching it happen right now.

Re: SSL certificate requirements are becoming obnoxious

#148

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.

That's six years obsolete, without security patches. What sector has 20% of users with that hardware?

Re: SSL certificate requirements are becoming obnoxious

#149
post #68

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…

Support contract states we cannot put it behind a proxy. We used to use HAProxy and multiple web server instances, but the support switched to India and they claimed they could no longer undertsand or support that configuration. Since it is a main system for the entire org and the support contract is part of our financial liability and data insurance, the load balancer had to go. This is corporate enterprise IT. Now you know why sysadmins are so grumpy.

Re: SSL certificate requirements are becoming obnoxious

#150

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…

Lazy vendors. I know how to set up Let's Encrypt for web servers that I directly control, but some of the web servers are embedded in commercial vendor products. If this were just about people's directly-controlled nginx/caddy webservers this would be easy. We're not talking about homelabs here.
Post reply on HN