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

151–160 of 179 posts

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

#151

Post by Mister_Snuggles »

labawi wrote: post #120
tialaramex wrote: post #49

Earlier quoted context omitted.

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.

If you're doing it from the machine where your CA is, and using secure transport, then it shouldn't be less secure than doing the CSR/Sign/Certificate dance. I mean, it would be nice, especially if you are distributing to other people, but I don't really see a difference if we are talking about uploading cert/keys to servers where you have root access.

My desire to learn how this works still applies.

But if I'm dealing with this sort of thing in outside of my homelab it'd be nice to see how it all works. I figure that learning how the CSR dance works in my homelab will help me understand how it works in the real world.

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

#152

Post by castillar76 »

xg15 wrote: post #134
castillar76 wrote: post #124

Earlier quoted context omitted.

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's not terribly painful to do if you have central management (e.g. you can push them out through a GPO or MDM system). For small businesses, however, I totally agree it's a pain in the neck: the school my wife teaches at would have a devil of a time doing it with their current IT staff workload, and they'd still have issues with unmanaged devices. And all that's to say nothing of the ticking time-bomb that occurs when you set up your own PKI--good luck remembering to replace that root CA ten years down the line when it explodes.

The cynical part of me says that certain companies might be very interested in the search possibilities gained from exposing internal networks to the Internet, and the increasing lock-in that occurs when you make your systems dependent on their public CA instead of your own private one. But perhaps that's just the tinfoil-hat talking. :)

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

#153

Post by castillar76 »

j1elo wrote: post #135
castillar76 wrote: post #119

Earlier quoted context omitted.

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

No, Apple was clear that this change (the 13-month limit) only affects public certificates, so internal private PKIs and self-signed certificates retain the two-year limit from before. I think that that two-year limit extends to every certificate used for TLS in the system, so there's no way to get around it by manually trusting the certificate or CA chain (there's no 'development use' flag on certs), but that bears testing.

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

#154

Post by wbond »

Apple is the reason I just switched a handful of certificates from Let’s Encrypt to basic 2 year DV.

To support Apple Pay on the web, you have to go to your developer account on the Apple website, and under certificates generate a custom ASN.1 authentication file and upload it to the `/.well-known/` folder on your domain. Once uploaded, you have to click a “Verify” link, to check the file and mark the domain as Apple Pay approved. The issue is the verification only lasts as long as the certificate expiration, and if a new certificate is installed, you have to re-verify the domain with a newly generated authentication file, for each domain. A fresh certificate with an old authentication file does not work.

This means if using Let’s Encrypt, you have to manually step through the verification process for each of your production, staging and development environments every three months. There doesn’t appear to be any automated way to handle this.

After two cycles of this I opted to purchase 2-year certificates just to save the hassle of re-authenticating my web environments on a rolling basis by hand.

This announcement just means more frequent manual processes once again. What a pain.

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

#155

Post by tptacek »

Reelin wrote: post #150
tialaramex wrote: post #147

Earlier quoted context omitted.

"Standard" is a big ask. If this is a concern then you can proceed as follows: 1. Wait 24 hours or so after securing control over the names. 2. Use the Certificate Transparency logs to determine which certificates if any exist for names you now control and want revoked. 3. Discover the revocation process for the issuer of each cert. 4. Use each process you discovered. All of them should be willing to revoke if you ca…

Thanks for another clear explanation of process! But... the fact that there isn't some standardized automated revocation procedure that all CAs are required to support at this point seems somewhat absurd to me. At a minimum, it seems like such processes based on both proof of domain ownership and proof of private key possession should exist. Moreover, there ought to be a way to specify via DNS which CAs can issue cer…

You're thinking of CAA, which in theory works even if only the CAs look at the records, which is important because no browser will; all mainstream browsers have abandoned DNSSEC, which is moribund.

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

#156

Post by hoistbypetard »

jsjddbbwj wrote: post #145
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…

Sorry if this sounds dumb but this is a non sequitur for me. How does the for-profit web benefit from being able to revoke certificates? And why does revocation not work in practice? I thought all major browsers check their own lists to see if certs are revoked

This paper:

https://cseweb.ucsd.edu/~schulman/docs/imc15-revocation.pdf

is slightly dated but gives a very good rundown of how revocation checks fail in practice along with different attempts to improve them.

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

#157

Post by alwillis »

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.

Browsers toyed with the idea of using DNSSEC + DANE which would allow a website owner to use self-signed certificates and have them trusted just like commercial certificates.

A DNS record (TLSA) would tell the browser how to deal with trusting the certificate, its public key or to validate the chain of certificates, etc: https://www.rfc-editor.org/rfc/rfc7671.html.

This would have radically changed the landscape of certificate authorities and browser vendors.

Google and Mozilla implemented it back in the day but changed directions. Among other issues, doing additional DNS lookups when you're trying to get the page on the screen as quickly as possible put the kibosh on things. Plus politics.

Mind you, using DANE + TLSA is the defacto standard for Mail Transfer Agents to do secure email with each other but SMTP and HTTP have different security requirements.

We may eventually get there, but there are political and technical hurdles to overcome when it comes to DNSSEC, which is required for DANE and all the rest. It's really taken off in parts of the European Union, South America, and Asia, but not so much in the US, where only about 25% of internet users are behind a DNSSEC-aware resolver: https://stats.dnssec-tools.org.

The article DNSSEC, DANE and the failure of X.509 is a pretty good summary: https://blog.hansenpartnership.com/dnssec-dane-and-the-failu....

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

#158

Post by cutler »

Just look at the state of the "modern" internet with it's certification wars, 2-level auth, Google SMTP gatekeeping, mandatory HTTPS, Letsencrypt v2 & certbot renewal fsck-ups. What hope in hell does the ordinary user have of navigating all this? Do we all now need to be experienced sysadmins just to use the internet?

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

#159

Post by cutler »

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…

Fsck certificates, period. Make an exception for ecommerce and banking sites but leave the rest of us alone. Certificates have become the equivalent of the UK's national policy of building road humps 50 metres apart to thwart speeding drivers.

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

#160

Post by cutler »

extra88 wrote: post #137
xg15 wrote: post #131

Earlier quoted context omitted.

> 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.

Yeah, right - and risk the wrath of your clients when they ask you why their shiny new website can't be accessed because it doesn't implement HTTPS. Face it, folks, the golden age of the internet is long past. Now we have to jump through a bewildering array of "security" hoops just to host a ing web page.
Post reply on HN