Live data from Hacker News

SSL certificate requirements are becoming obnoxious

chrislockard.net

161–170 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#161

There's two sides to this, if it's not a public service, why should it have a certificate from a public CA? If your risk assessment says that you do not need MPIC, then just don't do that, yourself. The second side is that if it's so tedious to approve and install, use solutions that require neither. Surely you don't need to have some artisanal certificate installation process that involves a human if you already adm…

"If it's not a public service, why should it have a certificate from a public CA?" Probably because making sure that clients trust the right set of non-public CAs is currently too much of a pain in the ass. Possibly an underrated investment in the security of the internet would be inventing better solutions to make this process easier, the way Certbot made certificate renewal easier (though it'd be a harder problem a…

> Probably because making sure that clients trust the right set of non-public CAs is currently too much of a pain in the ass. Possibly an underrated investment in the security of the internet would be inventing better solutions to make this process easier.

I don't see a reason why that should be a problem to solve for public CAs and rest of the internet? Complaining about multi-perspective validation or lifetime is silly if the hindrance is someone's own business needs and requirements.

Re: SSL certificate requirements are becoming obnoxious

#162
post #82
post #37

Earlier quoted context omitted.

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.

... which is also the solution for any other infrequent manual process. :)

Re: SSL certificate requirements are becoming obnoxious

#163

Earlier quoted context omitted.

What would it look like for the Web PKI to "not survive that change"? Is the idea that companies stop having websites and tell all their users to switch to Gopher or something, because the burden of certificate management is too much? > In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum. Good. A certificate being publicly trusted is a liability , w…

> What would it look like for the CA/B to "not survive that change"? I suspect when companies who are members actually realize what happened, CA/B members will be told to reverse the 47 day lifetime or be fired and replaced by people who will. This is a group of people incredibly detached from reality, but that reality is going to come crashing through to their employers as 2029 approaches. > Good. You may assume tha…

Who exactly in the CA/B member companies is going to demand that the 47-day lifetime be reversed, and why are they going to do that?

If an org is tech-forward enough to have bothered setting up HTTPS for internal use cases on their own initiative, just because it was good for security, then they're not going to have major problems adapting to the 47-day lifetime. The orgs that will struggle to deal with this are the ones that did the bare minimum HTTPS setup because some external factor forced them to (with the most obvious candidate being browsers gradually restricting what can be done over unencrypted HTTP). Those external factors presumably haven't gone anywhere, so the orgs will have to set up private CAs even if they'd rather not bother.

Re: SSL certificate requirements are becoming obnoxious

#164

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…

Yeah, we went from "software is a good that can be duplicated with no cost" to "software can be a service" to "software must be a service".

Re: SSL certificate requirements are becoming obnoxious

#165
post #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.…

There are more ACME-compatible CAs than just Let's Encrypt, should they ever become the bad guys, or if you don't want to trust them for any reason, see [0].

I understand that people get annoyed at shorter cert lifetime, for instance if you are managing appliances or use SSL certs for other reasons than the common use case. But if you just want to serve a website, there are not so many reasons not to use HTTPS today, either on Let's Encrypt or on something else.

[0] https://acmeclients.com/certificate-authorities/

Re: SSL certificate requirements are becoming obnoxious

#166

Earlier quoted context omitted.

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…

It is solved but devices you are talking about refuse to get on board with the fix so here we are. Also, I used to do IT, I get it but what do you think the fix here is? You could also run your own CA that you push to all the devices and then you can cut certificates as long as you want.

Where I am right now, if devices cant do what regulator and internal security asks, we find a new vendor.

Re: SSL certificate requirements are becoming obnoxious

#167
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…

> 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). How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? The updated (full color!) Panelview HMI is running Windows CE 6.0, so it's perhaps more likely to be compatible, but I don't think…

>How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM?

You dont and you are not supposed to bend security posture backwards to accomodate insecure devices that should be in the landfill by now

Re: SSL certificate requirements are becoming obnoxious

#168

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 regulatory requirements: yes ! I currently for EIDAS certificates, I can only choose a vouched certificate provider, and it's mostly somes that requires me to in person with my ID card with someone verifying the guy who made the CSR is actually me. The certificate is used for double SSL to authentify the server doing the request , i.e that the server doing an API call to the bank server is one I own. (I find it a…

Well, its eidas, ofc you need to show the id

Re: SSL certificate requirements are becoming obnoxious

#169
post #117
post #52

Earlier quoted context omitted.

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.

"Just use Nginx" was not a viable option here, without additional Certbot etc. orchestration, until 14 days ago! And this is still in preview! https://blog.nginx.org/blog/native-support-for-acme-protocol

And, if you haven't been using a reverse proxy before, or for business/risk reasons don't want to use your main site's infrastructure to proxy the inherited site, and had been handling certificates in your host's cPanel with something like https://www.wpzoom.com/blog/add-ssl-to-wordpress/ - it is indeed a dedicated project to install a reverse proxy!

Re: SSL certificate requirements are becoming obnoxious

#170

Earlier quoted context omitted.

On the vulnerability ladder since SSL was introduced, how common and how disastrous have stolen or fraudulent certs really compared to other security problems, and by how much will these changes reduce such disasters?

China currently has a large APT campaign using a comprised CA (Billbug). https://www.darkreading.com/endpoint-security/china-based-bi...

I agree with the article, this is "potentially very dangerous". Potential is not actual though, and I'm asking about what damage has actually materialized. Is there a cost estimate over the past 20 years vs. say, memory safety vulnerabilities?
Post reply on HN