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

121–130 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#121

Post by watusername »

To be frank, the whole post reads like "I hate change" with no convincing argument otherwise. The author even acknowledges the very lenient ramp-up from CAB _and_ the myriad of available tooling, yet still throws his hands up.

> I am responsible for approving SSL certificates for my company. [...] I review and approve each cert. What started out as a quarterly or semi-monthly task has become a monthly-to-weekly task depending on when our certs are expiring.

I don't get the security need for manually approving renewals, and the author makes no attempt to justify this either. It may make sense for some manual process to be in place for initial issuances, as certificates are permanently added to a publicly-available ledger. And to take a step back, do you need public certs to begin with? Can you not have an internal CA? Again, the author makes no attempt to justify this, or demonstrate understanding in the post.

> email-based validation may as well not exist when we need to update a certificate for test.lab.corp.example.com because there is no webmaster@test.lab.corp.example.com.

I know that this is an example, but as a developer it would be a pain to have to go through a manual, multi-day process for my `test.lab.corp.example.com` to work. And the rest of the post seems to imply that this is actually the case at OP's org.

> Which resource-starved team will manage the client and the infrastructure it needs? It will need time to undergo code review and/or supplier review if it’s sold by a company. There will be a requirement for secrets management. There will be a need for monitoring and alerting. It’s not as painless as the certificate approval workflow I have now.

There are additional costs and new processes to be made, yes, but even from a non-technical POV this appears to be a good time to lead and take ownership.

> Any platforms that offer or include certificate management bundled with the actual services we pay for will win our business by default. [...] What is obvious to me is that my stakeholders and I are hurrying to offload certificate management to our vendors and platforms and not to our CA.

That's okay. If you hate change and don't want to take ownership, pay someone else to take ownership.

Re: SSL certificate requirements are becoming obnoxious

#122

Post by 9dev »

whatevaa wrote: post #111
9dev wrote: post #88

Earlier quoted context omitted.

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?

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.

Re: SSL certificate requirements are becoming obnoxious

#123

Post by znpy »

trenchpilgrim wrote: post #85
o_m wrote: post #60

Earlier quoted context omitted.

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.

There are paid ACME services - basically LE with paid support.

Yeah, one of those is https://zerossl.com/

Re: SSL certificate requirements are becoming obnoxious

#124

Post by ameliaquining »

ocdtrekkie wrote: post #6

I do not think PKI will survive the 47 day change. I am not sure the CAB will survive that change. It seems extremely apparent the people who made the decision have neither any relevant experience in IT nor any practical understanding of security, and I think they've finally flown too close to the sun. Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer. In o…

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, which is why there are all these stringent requirements around it. If your certificates do not in fact need to be trusted by random internet users, then the CA/B wants you to stop relying on the Web PKI, because that reduces the extent to which your maintenance costs have to be balanced against everybody else's security.

As I said in another comment, private CAs aren't that popular right now in the kinds of organizations that have a hard time keeping up with these changes, because configuring clients is too painful. But if you can do it, then by all means, do!

Re: SSL certificate requirements are becoming obnoxious

#125

Post by Thorrez »

8organicbits wrote: post #93
Thorrez wrote: post #46

Earlier quoted context omitted.

>Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? Then if your CA went down for an hour, you would go down too. With 47 days, there's plenty of time for the CA to fix the outage and issue you a new cert before your current one expires.

Lots of ACME software supports configuring CA fallbacks, so even if a CA is down hard for an extended period you can issue certificates with the others. Using LetsEncrypt and ZeroSSL together is a popular approach. If you need a stronger guarantee of uptime, reach for the paid options. https://github.com/acmesh-official/acme.sh?tab=readme-ov-fil...

If everyone uses that with 1 minute or 1 second expirations, I could certainly see a case where an outage in 1 CA causes traffic migration to another, causing performance issues on the fallback CA too.

>If you need a stronger guarantee of uptime, reach for the paid options.

We don't. If we had 1 minute or 1 second lifetimes, we would.

Re: SSL certificate requirements are becoming obnoxious

#126

Post by xnorswap »

ameliaquining wrote: post #108
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…

Is there a different implementation timeline that you think would adequately address the legitimate concerns of orgs relying on legacy and manual processes? My model is that beyond a baseline of a couple years (which were already granted), adding more time doesn't help, because these orgs will always procrastinate until the last minute on anything that doesn't seem to management like an obvious immediate priority. I…

Just extending the timeline won't help, as you suggest, if anything it'll make the problem even worse, by further bedding in the helpless.

What typically does work for this kind of thing, is finding a hook to artificially rather than technically necessitate it, while not breaking legacy.

For example, while I hate the monopoly that Google has on search, it was incredibly effective when they down-ranked HTTP sites in favour of HTTPs sites.

( In 2014: See https://developers.google.com/search/blog/2014/08/https-as-r... )

Almost overnight, organisations that never gave a shit, suddenly found themselves rushing through the any required tech debt to get SSL certs and HTTPs in place.

It was only after that drove up HTTPs to a critical mass did Google have the confidence to further nudge through bigger warnings in Chrome. ( 2018 ).

Perhaps ChatGPT and has impacted Google's monopoly too much to try again, but they could easily rank results based on certificate validity length and try the same trick again.

Re: SSL certificate requirements are becoming obnoxious

#127

Post by compumike »

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…

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 verify the TXT record as well, and cache that result for an hour or whatever you like?

Or another set of TXT records for revocation, TXT _acme-challenge-revoked. etc?

It's not perfect, DNS is not at all secure / relatively easy to spoof for a single client on your LAN, I know that. But realistically, if someone has control of your DNS, they can just issue themselves a legit certificate anyway.

Re: SSL certificate requirements are becoming obnoxious

#128

Post by dvdkon »

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?

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.

Re: SSL certificate requirements are becoming obnoxious

#129

Post by DougN7 »

ComputerGuru wrote: post #109

I actually don’t have a problem with the SSL changes as they specifically pertain to http servers – it’s largely a dived problem with automated solutions compatible with all the major players on most fronts. But certs and every other context have become neigh impossible except in enterprise settings with your own CA and cert servers. From things like printers and network appliances to entirely non-http applications l…

The last time I looked, if you ran your HTTPS service on anything other than port 443 LetsEncrypt was not for you. Maybe that’s built into ACME?

Re: SSL certificate requirements are becoming obnoxious

#130

Post by ameliaquining »

tialaramex wrote: post #114
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…

It's possible that this was just a slight imprecision of language, and the thing being inspected is the CSR rather than the actual certificate. (But the point about individual certificates/CSRs being unworthy of human attention is totally right.)
Post reply on HN