Live data from Hacker News

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

theregister.co.uk

81–90 of 179 posts

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

#81

Earlier quoted context omitted.

Can someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point. Any other explanation?

The issuer shouldn't know the private (not secret) key corresponding to the public key in the certificate anyway. In the Web PKI they're explicitly forbidden from knowing this key and good ones will react to being shown a private key by revoking any associated certificates -- that's what happened in the Trustico incident. They do know a private key for their entire CA certificate which they're using to sign things, b…

I agree with your overall point and appreciate the clear explanation. However, I'd like to suggest that perhaps what you describe as "merely precautionary changes" should never occur on anything less than a ~2 year timescale anyhow. If it's urgent, go right ahead and break things. But the internet is _big_, and modifications can be _expensive_, so precautionary changes should probably occur quite slowly at this point.

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

#83
post #37

Earlier quoted context omitted.

Can someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point. Any other explanation?

Without an expiration date the only way to retire a certificate would be to explicitly revoke it. That'd be a bit heavy handed IMO. Forcing certificates to expire means that domain ownership gets re-validated every time. Nobody would risk buying 2nd-hand domains for anything sensitive if the previous owners could have a permanently valid certificate stashed somewhere. Or you'd have to contact all the CAs that could'v…

Is there not already a standard procedure for certificate revocation on domain ownership transfer? It seems like there really should be - even a 13 month expiry is hardly enough to prevent intentional abuse.

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

#84

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…

I am telling you there is a conspiracy going on to end the open and free web. We should fiercefully start to fight back otherwise those who made the internet great (the open source hackers working on LAMP) will loose everything.

Does apple try to kill the web? Does Google try to take it over?

Why doesn't Apple kill a million sh.tty apps just trying to grab attention doing nothing useful?

It's time to get rid of Apple/Google browsers really

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

#85

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?

The two big reasons for short certificate validity periods are to manage revocation issues (expiry is the one guaranteed way to revoke a certificate), and to reduce the risk of forgetting to renew certificates (by having to rotate them more frequently, your IT is more likely to have better processes in place). There's a secondary concern of reducing the ability of CAs to backdate certificates (which happened when SHA-1 was prohibited).

Neither of those really apply to the root certificate store. Updating the root certificate (to add or remove CAs) requires an OS/browser update instead of relying on CRL or OCSP queries which are flakier--and browsers have a variety of mechanisms to punish misbehaving CAs that aren't "drop you from the root store effective immediately."

Meanwhile, the process for updating root stores is entirely different than regular certificates, and it takes months to years to add a new root certificate--and I believe you don't get a pass to merely update your new root certificate for an existing CA.

The other risks with overly long validity times are ameliorated in large degree by the fact that CAs are regularly audited and have much greater scrutiny placed on their issuance.

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

#86

Earlier quoted context omitted.

Can someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point. Any other explanation?

> the issuer [...] are saying that they can't guarantee that they will still be the only person with the secret key after that point. It's not quite clear what you mean here. The issuer should never have the private key for the end-entity cert (the one representing the domain or whatever). Only the owner should have the private key. EDIT: Hmm, according to another comment here, some CAs will offer to generate both ha…

The latter did already happen: Diginotar, in 2011. The Dutch government tried to restrain browser makers from revoking Diginotar's certificates, since many of their websites and services used them. It's a good thing certificates don't have an eternal life span.

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

#87

Earlier quoted context omitted.

oh, I completely agree that certificate transparency is beneficial for that and we have an alert setup. But, that still leaves me not wanting to leak every single subdomain we use internally. Hence using wildcard certificates.

CT didn't change this for bad guys. If you're a bad guy (or a neutral researcher with a budget for the data) you can buy what's called "Passive DNS". Several suppliers will give you a list of DNS requests and their answers, the identifying information for who made the requests is elided so it's not PII but it has the same effect of making the fact servername.example.com exists in effect public information. Even if yo…

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.

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

#88
post #41
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.

The likely result is that two year certs will just cease to be available, even if other clients don't decide to make an equivalent rule.

And yes, the de facto standard is that for the general purpose web you can't sell certificates based just on, for example, getting an OK from Microsoft (whose trust stores includes a tonne of governments and government agencies whose inclusion a cynic might assume is not coincidental to those governments agreeing to purchase Microsoft's products...) because those certificates don't work on an iPhone or in Firefox or...

The relationship that is symbolised by the CA/Browser Forum has always been asymmetrical like this, it was this way before the CA/B Forum was created, and if the two groups aren't able to reach common ground the CA/B will just gradually go away.

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

#89

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 front of it.

So I don't really understand what you're talking about, when the price and ongoing maintenance of HTTPS certificates has gone significantly down for hobbyists.

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

#90

Earlier quoted context omitted.

Can someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point. Any other explanation?

> the issuer [...] are saying that they can't guarantee that they will still be the only person with the secret key after that point. It's not quite clear what you mean here. The issuer should never have the private key for the end-entity cert (the one representing the domain or whatever). Only the owner should have the private key. EDIT: Hmm, according to another comment here, some CAs will offer to generate both ha…

> EDIT: Hmm, according to another comment here, some CAs will offer to generate both halves of the keypair for the end user. Yikes.

I wasn't able to find this comment, but perhaps I didn't look hard enough? EDIT: Wait, I think I found it. I will reply there.

In the Web PKI this is prohibited but there are or at least were resellers who'd offer this service to their customers. You should not use this service of course, and some CAs have pledged to tell their resellers not to offer it.

In S/MIME it's more common because often the end user is both technically unsophisticated and not given real control over their client in order to mint their own keys anyway. But S/MIME is... probably not important, certainly it isn't what Apple's change is about.

Post reply on HN