Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safari will no longer trust certs valid for more than 13 months

theregister.co.uk

Post reply on HN
Print view View original

51–60 of 179 posts

Re: Safari will no longer trust certs valid for more than 13 months

#51

Post by PureParadigm »

Mister_Snuggles wrote: post #44

I have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication. Is th…

Use a web browser that respects your choices. Your software should work for you, not the other way around.

Re: Safari will no longer trust certs valid for more than 13 months

#52

Post by luckylion »

derefr wrote: post #42
superkuh wrote: post #39

There are two mutually exclusive views of the web. As a set of protocols to allow individual humans to share information about things they love and the web as a set of protocols to make a living. There are real reasons for the for-profit web to want to limited cert lifetimes since revocation doesn't really work in practice. In terms of browser dev the two views are mutually exclusive and the one that funds the coders…

CAs have always been third-party services, though. Their APIs just used to involve humans talking to humans, rather than machines talking to machines. But that's no less of an operational dependency. In a systems engineering plan (e.g. a NASA long-term project), both kinds of dependencies are considered liabilities that must be engineered for long-term reliability, fault-tolerance, etc.

It's different if you can "buy" a cert and be "safe" for a few years vs needing to renew it every 90 days. If they choose not to renew your cert, you're out after what ever time is left on your cert.

Let's lower that to 60 ... 45 ... 15 .. ah, let's just renew all certs every day, that's the only way to keep control centralized.

Re: Safari will no longer trust certs valid for more than 13 months

#53

Post by j1elo »

Anybody knows why Safari on iOS will reject using self-signed certificates for WebSocket connections? (doesn't happen on desktop)

This is a major annoyance since it is the only browser that does this and won't work with "wss://" URIs even after accepting the mandatory certificate exception. Accessing the page rightfully shows a warning on all browsers, to which the user can click on "Continue" or similar, to ignore this and start the demo, except if they try with iOS (this is for simple one-off tutorials or demos [1], so maintaining good certs or requesting users to install a custom root CA in their devices is out of the question).

I know, this seems like a StackOverflow question... but the only 100% relevant one I found [2] didn't get much love, so I thought maybe someone at HN knows more about this

[1]: https://github.com/Kurento/kurento-demos-js/tree/master/play...

[2]: https://stackoverflow.com/questions/36741972/using-a-self-si...

Re: Safari will no longer trust certs valid for more than 13 months

#54

Post by luckylion »

tambre wrote: post #34
wool_gather wrote: post #31

Earlier quoted context omitted.

It's basically what has been announced here, though, no? There's no technical impediment to a CA continuing to hand out 2+ year certs. The only reason they would not do so is that webpages will start breaking if they're accessed from Safari.

The criteria are very clear: - Safari - max 398 days

> The criteria are very clear:

today. Tomorrow they may change to be 397 days, or 39.8 days, or "until the next iPhone is released".

Re: Safari will no longer trust certs valid for more than 13 months

#55

Post by userbinator »

jakub_g wrote: post #7
stygiansonic wrote: post #5

I understand the reasons behind wanting to shorten certificate validity periods, but CA or root certificates often have expiration periods far into the future. What’s the argument for this? Ease of use? Historical reasons?

It's not easy to (at least this was the case until a few years ago) to ship updates to an old device (think Android 4.x or Windows XP; even worse for embedded systems). Hence to avoid the devices become useless bricks even if otherwise fully functional, root certs need to have more than a decade cert validity at minimum. (That's my personal theory, I'm not in the industry).

I think the industry is very much trying to push for the exact opposite of that, with things like planned obolescence to ensure you keep consuming their latest products.

Re: Safari will no longer trust certs valid for more than 13 months

#56

Post by Wowfunhappy »

PureParadigm wrote: post #51
Mister_Snuggles wrote: post #44

I have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication. Is th…

Use a web browser that respects your choices. Your software should work for you, not the other way around.

Users can choose to manually trust expired certs in macOS/iOS, I don't believe that's what is at issue here.

Re: Safari will no longer trust certs valid for more than 13 months

#57

Post by Mister_Snuggles »

tialaramex wrote: post #49
Mister_Snuggles wrote: post #44

I have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication. Is th…

If you're moving Private Keys you are Doing It Wrong. This is very common in VPN setups (and S/MIME) but still a terrible idea and worth taking the time to figure out how you'll make sure you don't do this.

I'm definitely open to learning how to do things better, and I have no doubt that some of what I'm doing is wrong - after all, this whole thing started as a homelab-turned-homeprod learning experience.

I think the proper way to do certs is to have the server (Web, VPN, whatever) create a certificate signing request and private key on the server, send the signing request to the CA to sign it, and then install the resulting signed cert on the server. Is this correct?

What I'm finding in some cases is that there are cases where this just won't work. For example, my QNAP NAS allows me to either create a self-signed certificate (I don't want this, I want it signed by my CA), get one from Let's Encrypt (same issue), or upload certificate, private key, and optional intermediate CA certificate files (and we're back to moving private keys). This is a limitation of QNAP's GUI for sure, but it's not unique to QNAP.

Similarly, I'm not sure how I'd generate the certificate plus private key on an iOS device and submit it for signing (the VPN scenario). This one particularly bothers me because the .mobileconfig file ends up being the key to the castle. Ideally I'd like the client to be authenticated with both a user-specific certificate and EAP, but I don't think iOS supports this. I haven't quite gone very far down this rabbit hole, so it's possible that I'm missing something.

When I finally secure my internal web server (which acts as a reverse proxy for all of my internal services), I'll try the CSR approach for the learning experience. This approach should also work fine on my VPN server.

Re: Safari will no longer trust certs valid for more than 13 months

#58

Post by Wowfunhappy »

User23 wrote: post #41
hannob wrote: post #27

Earlier quoted context omitted.

That is... a very absurd idea. You really don't want a situation where webpages may work or not work based on some completely unclear criteria.

This is exactly what Safari deciding to arbitrarily not trust valid certs is. The de facto standard will be that you will need to accommodate the least tolerant user agent if you want your certs to work for all browsers.

But Safari has laid out clear criteria as to under what conditions the certs will be invalid.

If I'm understanding correctly, the GP is saying browsers should be making decisions based on a much wider variety of criteria (for example, who issued the cert, how popular is the website using the cert, etc), which would be much more difficult to troubleshoot.

Re: Safari will no longer trust certs valid for more than 13 months

#59

Post by jaywalk »

z3t4 wrote: post #45

I don't think certificates are a good solution for most websites. Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. Also browser should send their public key to the server! So that we don't have to come up with a new password for every damn site.

>Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH.

The vast majority of users will not understand this. Also let's say you go to a site one day, and you get a prompt that their certificate has changed. Is this legit? How can you know?

>browser should send their public key to the server!

This already exists (HTTPS Client Certificates) but it's a huge pain in the ass so it's barely ever used. When it is used, it's generally within a controlled corporate environment.

Re: Safari will no longer trust certs valid for more than 13 months

#60

Post by gruez »

superkuh wrote: post #48
derefr wrote: post #42

Earlier quoted context omitted.

CAs have always been third-party services, though. Their APIs just used to involve humans talking to humans, rather than machines talking to machines. But that's no less of an operational dependency. In a systems engineering plan (e.g. a NASA long-term project), both kinds of dependencies are considered liabilities that must be engineered for long-term reliability, fault-tolerance, etc.

In the past browsers did not scaremonger so much about self-signed certs and search engines would index sites that were just http and this didn't effect their ranking.

>In the past browsers did not scaremonger so much about self-signed certs

That's necessary because people tend to be fixated on whatever task they're doing, and that causes them to click pass any warnings regardless of risk or comprehension.

Post reply on HN