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

221–230 of 305 posts

Re: SSL certificate requirements are becoming obnoxious

#221

Post by dspillett »

nikanj wrote: post #198
Shank wrote: post #173

Earlier quoted context omitted.

I feel like a lot of these requirements need to be really solved from first principles. What do you need these certificates for -- specifically, TLS certificates? If the biggest issue is "we want to encrypt traffic" then the answer really should be something more automated. To put it another way, TLS certificates used to convey a lot of things. We had basic certs that said "you are communicating with the rightful own…

What do I need these certificates for? I need them because browsers have started equating a vanilla http server to a malware-infested North Korean honeypot

> browsers have started equating a vanilla http server to a malware-infested North Korean honeypot

It isn't that they are equal, just that it is difficult to tell them apart. The change over time is that UAs have more and more erred on the side of not trusting when there is any question.

Of course HTTPS sites with valid certificates could also be malware infested hot zones, but it is less likely. Sites with invalid certs are more likely to be a problem than those with no cert (the situation might imply a DNS poisoning issue for instance), and sites with no cert are a higher risk than those with a valid one.

At least we seem to have dropped the EV cert theatre, the extra checks done before issuing one of those were so easy to fake or work around in many cases that they essentially meant nothing [source: in DayJob we once had an EV cert for a client instance, and I know how easy it was to get because I was the person at our end who applied for it and installed it once issued].

Re: SSL certificate requirements are becoming obnoxious

#222

Post by moduspol »

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…

I don't know about OP but I've also worked plenty of places where I seem to be the only person who understands TLS.

And not even at the "math" level. I mean, like, how to get them into a Java keystore. Or how to get Apache or nginx to use them. That you need to include the intermediate certificate. How to get multiple SANs instead of a wildcard certificate. How to use certbot (with HTTP requests or DNS verification). How to get your client to trust a custom CA. How to troubleshoot what's wrong from a client.

I think the most rational takeaway is just that it's too difficult for a typical IT guy to understand, and most SMBs that aren't in tech don't have anyone more knowledgeable on staff.

Re: SSL certificate requirements are becoming obnoxious

#223

Post by 9dev »

FuriouslyAdrift wrote: post #143
9dev wrote: post #122

Earlier quoted context omitted.

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.

Well. That, or maintaining bespoke PKI and internal CA, along with manually renewing certificates with ever-shortened expiration periods as demanded by browsers.

Pick your poison.

Re: SSL certificate requirements are becoming obnoxious

#224

Post by jtbayly »

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…

One example is FreePBX, which supposedly supports automated SSL renewal via LetsEncrypt, but constantly overwrites the config, thus breaking the “auto.” So I have to manually renew the cert, or I have to upgrade (ie rebuild the whole system from scratch, including installing the OS) to the next major version of FreePBX and hope they fixed the issue.

So I’m really not excited about the time limit dropping from 90 days to 47 days.

Re: SSL certificate requirements are becoming obnoxious

#225

Post by 9dev »

nikanj wrote: post #206
9dev wrote: post #86

Earlier quoted context omitted.

Oversight over… what exactly? TLS certificates don't need human oversight. If you want to see which certificates have been issued for your domains, set up certificate transparency monitoring. But thank goodness we're past paying people for comparing certificate checksums.

Schrödinger's certificates are so mundane they don't need human oversight, but are so precious they need to be renewed every 47 days

Your point is..? That applies to a lot of automatically maintained infrastructure, and it works just fine.

Re: SSL certificate requirements are becoming obnoxious

#226

Post by 9dev »

moduspol wrote: post #222
darkwater wrote: post #110

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

I don't know about OP but I've also worked plenty of places where I seem to be the only person who understands TLS. And not even at the "math" level. I mean, like, how to get them into a Java keystore. Or how to get Apache or nginx to use them. That you need to include the intermediate certificate. How to get multiple SANs instead of a wildcard certificate. How to use certbot (with HTTP requests or DNS verification).…

> I think the most rational takeaway is just that it's too difficult for a typical IT guy to understand, and most SMBs that aren't in tech don't have anyone more knowledgeable on staff.

Where would that kind of thinking lead us..? Most medical procedures are too complex for someone untrained to understand. Does that mean clinics should just not offer those procedures anymore, or should they rather make sure to train their physicians appropriately so they’re able to… do their job properly?

Re: SSL certificate requirements are becoming obnoxious

#227

Post by 9dev »

FuriouslyAdrift wrote: post #149
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…

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…

My condolences:)

Re: SSL certificate requirements are becoming obnoxious

#228

Post by plorkyeran »

TurboSkyline wrote: post #219
Shank wrote: post #173

Earlier quoted context omitted.

I feel like a lot of these requirements need to be really solved from first principles. What do you need these certificates for -- specifically, TLS certificates? If the biggest issue is "we want to encrypt traffic" then the answer really should be something more automated. To put it another way, TLS certificates used to convey a lot of things. We had basic certs that said "you are communicating with the rightful own…

> But the thing is, we've killed off a lot of these certificate types. We don't have EV certs anymore. EV certificates are no longer in use? Do you know why?

They turned out to be expensive theater. One major problem is that company names aren't actually unique. An EV cert for "Stripe, Inc" still doesn't tell you that you're talking to the correct "Stripe, Inc". The other big problem was that users had no clue they were a thing, and when browsers tried to emphasize them in the UI it just confused users and made phishing easier.

You can still buy EV certs if you want to donate money to a CA, but that's about all they accomplish.

Re: SSL certificate requirements are becoming obnoxious

#229

Post by whynotmaybe »

mrgaro wrote: post #217
TrueDuality wrote: post #196

Earlier quoted context omitted.

Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates. - Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal) - All infrastructure changes need to have the commands executed and con…

What dictates that certificate update needs to have a manual change process? I'd bet that it's just legal team saying that "this is how it's always been" instead of adjusting their interpretation as the environment around changes.

Yes, those rules always come from legal.

In some regulated places, someone is legally responsible for authorizing a change in production.

If it fails, that person's on the hook. So the usual way is to have a manual authorization for every change. Yes, it's a PITA.

One place I've worked changed their process to automatically allow changes in some specific parts for a specific period during the development of a new app.

And for some magical reasons, the person usually associated with such legal responsibility are the one that don't trust automatic process.

Re: SSL certificate requirements are becoming obnoxious

#230

Post by moduspol »

9dev wrote: post #226
moduspol wrote: post #222

Earlier quoted context omitted.

I don't know about OP but I've also worked plenty of places where I seem to be the only person who understands TLS. And not even at the "math" level. I mean, like, how to get them into a Java keystore. Or how to get Apache or nginx to use them. That you need to include the intermediate certificate. How to get multiple SANs instead of a wildcard certificate. How to use certbot (with HTTP requests or DNS verification).…

> I think the most rational takeaway is just that it's too difficult for a typical IT guy to understand, and most SMBs that aren't in tech don't have anyone more knowledgeable on staff. Where would that kind of thinking lead us..? Most medical procedures are too complex for someone untrained to understand. Does that mean clinics should just not offer those procedures anymore, or should they rather make sure to train…

Well I mean there's no inherent requirement that PKI work the way it does. We've mostly just accepted it because it's good enough.

Even if your server admins fully understand TLS, there are still issues like clock skew on clients breaking things, old cipher suites needing to be reviewed / sunset, users clicking past certificate warnings despite training, and the list of (sometimes questionable) globally trusted CAs that the security of the Internet depends upon.

Of course they should do their job properly, but I'm skeptical that we (as software developers) can't come up with something that can more reliably work well.

Post reply on HN