Live data from Hacker News

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

theregister.co.uk

131–140 of 179 posts

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

#131

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…

With Let's Encrypt it's cheaper than ever to host a personal website over HTTPS with a certificate that updates itself. Due to Let's Encrypt, free hosting services like Netlify or GitHub Pages are now providing HTTPS certificates and installing it on your own server is pretty painless, if you're into managing your own server. And if your hosting provider doesn't support Let's Encrypt, you can always put Cloudflare in…

> Let's Encrypt [...] Netlify [...] GitHub Pages [...] your hosting provider [...] Cloudflare

Those are exactly the kind of third-party services the GP was talking about.

> if you're into managing your own server

One of the core advantages of having a personal server has always been that you can keep it entirely off the internet and run it without any involvement of third-party services. That is not anymore possible. Like, I now need to purchase a domain name and set up infrastructure to fulfill Let's Encrypt's challanges, just so I can serve a page on my LAN.

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

#132
post #102

Earlier quoted context omitted.

> Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future. I mean... How do you expect to have a valid, trusted TLS certificate without a third party? Nobody says it has to be Lets Encrypt or Cloudflare or Amazon load balancers or ... so forth. Some certificate authorities even already have APIs....

No third party is strictly necessary. You have to know what the servers public key is in a reliable way. That doesn't necessarily mean a third party has to be involved. Maybe you call them on the phone and check the fingerprint. Maybe it's your server and you sneakernet the key to your client. And to appease the dumb protocol you wrap it up as a certificate (self-signed) and accept yourself as trustworthy (what a con…

For the more concrete goal of having a valid TLS certificate that is trusted by browsers, you absolutely need a third party however.

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

#133
post #109

Earlier quoted context omitted.

There is a tangible benefit. For users. 64-bit only, Project Catalyst, BitCode, HTTPS only connections etc are examples of initiatives which definitely has caused pain to developers but has immensely benefited users as a whole. And if you don't passionately care about users then frankly find another platform to develop on.

>64-bit only how has that benefitted the user? Directly and measureably, no "it's 0.3% faster now" excuses.

Not having to load both 32-bit and 64-bit libraries into memory is an efficiency (and battery life) improvement on the system as a whole.

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

#134
post #87

Earlier quoted context omitted.

Yes, which is why you used to be able to have fully internal domains that are served by an internal DNS server and are never seen on the public internet.

You can still have this: it's called 'split-horizon' or 'split-brain' DNS. It can be tough to set up and maintain for large DNS environments, but not /that/ difficult even at that level. If you do this and you don't want those names in the public CT records, though, you have to implement a private internal PKI for those servers so they're not getting public certs. Or use a wildcard, which carries its own significant…

> you have to implement a private internal PKI for those servers so they're not getting public certs

This would also involve setting up a custom CA and distributing your CA cert to all machines that should be able to access the page. Good luck with that!

All of this is a ridiculous amount of effort to set up and maintain. It's a lot easier to just make the internal domains accessible to the internet and be done with it.

The effect being that networks are being nudged into exposing a lot more surface to the internet - and this somehow in the name of more security.

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

#135
post #53

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 t…

Apple recently (last fall) introduced a change that rejects all certificates that are valid for more than two years, whether they're public or private. I would double-check whether the self-signed certificates are valid for longer (many default self-sign processes make ten-year certs, for instance). Failing that, you may have to create a proper private PKI and get users to install the CA, or else use something like L…

Thanks! you gave me one thing to check. The certs are indeed made for 10 years validity, the idea being that they should just make the demo work for a long time, even if it is with a certificate warning.

I don't think it's worth the effort of setting up all the automatic renewal process with Let's Encrypt for what amounts to a quick static code example... so in principle I wanted to avoid having to set that up.

The contents of this article means that soon this 2-year maximum will become a 13-month maximum, right?

Is there any way to create these specific-purpose certs with some kind of "private use" or "development use" flag that allows not having to re-create them so soon? 13 months looks too short of a time period, I'm afraid nobody will remember to refresh the fake certs and the demos will break... for really no good reason (related to the code itself)

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

#137
post #131

Earlier quoted context omitted.

With Let's Encrypt it's cheaper than ever to host a personal website over HTTPS with a certificate that updates itself. Due to Let's Encrypt, free hosting services like Netlify or GitHub Pages are now providing HTTPS certificates and installing it on your own server is pretty painless, if you're into managing your own server. And if your hosting provider doesn't support Let's Encrypt, you can always put Cloudflare in…

> Let's Encrypt [...] Netlify [...] GitHub Pages [...] your hosting provider [...] Cloudflare Those are exactly the kind of third-party services the GP was talking about. > if you're into managing your own server One of the core advantages of having a personal server has always been that you can keep it entirely off the internet and run it without any involvement of third-party services. That is not anymore possible.…

You can use HTTP instead of HTTPS or you can use a self-signed cert.

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

#138

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…

With Let's Encrypt it's cheaper than ever to host a personal website over HTTPS with a certificate that updates itself. Due to Let's Encrypt, free hosting services like Netlify or GitHub Pages are now providing HTTPS certificates and installing it on your own server is pretty painless, if you're into managing your own server. And if your hosting provider doesn't support Let's Encrypt, you can always put Cloudflare in…

It’s not the price that’s concerning; it’s having external dependancies.

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

#139
post #117

Earlier quoted context omitted.

You definitely didn’t need, and most sites didn’t use SSL a decade ago.

DNS you always needed.

1) no.

2) There are multiple organizations running DNS and the general consensus is that there shouldn’t be a single organization running it (except ICANN which is generally careful to delegate the root and TLDs to other organizations.)

3) Just because you have one bad thing doesn’t mean it’s ok to have two.

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

#140
post #102

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…

> Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future. I mean... How do you expect to have a valid, trusted TLS certificate without a third party? Nobody says it has to be Lets Encrypt or Cloudflare or Amazon load balancers or ... so forth. Some certificate authorities even already have APIs....

A lot of other apps that use asymmetric crypto to authenticate the other end allow for “trust on first contact” for establishing trust.

It’s a little disappointing that many browsers have no support for this whatsoever and most have very poor support for it.

Post reply on HN