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

41–50 of 179 posts

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

#41

Post by User23 »

hannob wrote: post #27
lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

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.

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

#42

Post by derefr »

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.

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

#43

Post by diroussel »

hannob wrote: post #27
lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

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.

Yes but what we have now is also absurd. One day I can visit a site just fine and the very next I can’t and the browser won’t even let me override the “invalid” certificate.

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

#44

Post by Mister_Snuggles »

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 there any tool that I can use to help automate this in a reasonable manner?

Ideally, I'd love to see a web version of xca that supports ACME with some controls on how ACME certificates get issued. Bonus points for supporting OCSP as distribution of CRLs is another upcoming pain point.

[0] https://hohnstaedt.de/xca/

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

#45

Post by z3t4 »

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.

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

#46

Post by derefr »

gruez wrote: post #19
lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

> The client should decide whether the certificate is still trustworthy. Great, now you need to constantly go to some site like caniuse.com to see what % of browsers thinks your certificate is valid.

I mean, in a world with more than an oligopoly of browser makers, that'd already be true given that browsers each ship with their own trusted CA store.

In the original conception of X.509, it was supposed to be an enterprise's system administrator (e.g. a university's IT department) that would define the set of root CAs that the enterprise's computers would trust. So there'd be literally no way to know whether a given user device would trust your certificate. That was supposed to be a choice that is up to them, not something you can pre-guarantee by making deals with third parties.

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

#47

Post by pickdenis »

diroussel wrote: post #43
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.

Yes but what we have now is also absurd. One day I can visit a site just fine and the very next I can’t and the browser won’t even let me override the “invalid” certificate.

How about grading the validity of the certificate on a continuous scale? P(site loads) = 1 - R*(days since issue) where browsers can choose R as they wish. This gets rid of this discontinuity.

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

#48

Post by superkuh »

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.

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.

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

#49

Post by tialaramex »

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.

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

#50

Post by nimbius »

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…

check out Cloudflares CFSSL https://github.com/cloudflare/cfssl to manage the CA side, its API, and its OCSP

then check out Netflix Lemur for issuing and tracking certs automatically. https://github.com/Netflix/lemur

Post reply on HN