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

61–70 of 179 posts

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

#61

Post by dcow »

nimbius wrote: post #50
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

CFSSL was developed with cloudflare-specific use cases in mind. If you're looking for a general purpose personal CA, checkout smallstep/certificates: https://github.com/smallstep/certificates. Full disclosure, I work for smallstep, but we’re not exactly competitors. Regardless, here’s an external analysis of the two: https://jite.eu/2020/2/17/step-ca/

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

#62

Post by lmilcin »

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.

Well, you are mostly correct.

There are ways to distribute keys safely. You can use key derivation or you can set up transport key (yet another key, just to transport session keys). Both methods are allowed by PCI if done correctly.

Unfortunately that's not what typically happens. Setting up infrastructure to transport keys safely is such a pain in the ass that, for SSL/TLS, I always recommend to just generate the key at the site of its intended use.

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

#63

Post by tialaramex »

Mister_Snuggles wrote: post #57
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.

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

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

Yes. The CSR is public information so it's fine to send that somewhere. "Sign it" [the CSR] is a phrase that doesn't entirely reflect what's happening with the relationship between a CSR and Certificate, experts know it's technically wrong but they say it anyway, so don't sweat it but it's probably misleading.

I will try to circle back to see if I have any suggestions for your specific scenarios later.

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

#64

Post by z3t4 »

jaywalk wrote: post #59
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) b…

There could still be a trust chain. But most websites don't need it, just like most websites only use the basic level of certification today, all they really want is encryption. (or the green padlock :P)

Client certificates has kinda been deprecated by browsers. Which is why it's such a PITA. Also handling signing certificates by itself is a PITA. But most website's wouldn't need signing, just encryption.

Automatic SSL certificate signing is not that secure, if an attacker would be able to mess with DNS, or access the HTTP server, they could also create a fake certificate via Letsencrypt. Or if the attacker has access to the client, they could sneak in a root certificate. Most nation states and ISP (those who would like to spy on it's citizen) already have root certificates. All that SSL certificates do is to create extra work for site maintainers. We can have encryption without certificates. If you would for example side-load a list of public keys for the main sites you visit, that would be much more secure then SSL certificates are today.

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

#65

Post by chrisandchris »

luckylion wrote: post #54
tambre wrote: post #34

Earlier quoted context omitted.

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

Isn‘t that a bit like arguing about the 825 days? The CA/B could change that aby day they want and there‘s nothing you can do. Others will follow Apple and the CA/B will follow too, like they should have in 2017, IMHO.

The 398 days isn‘t something they came up right before they presented it. It‘s already 3 years old...

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

#66

Post by tialaramex »

abdullahkhalids wrote: post #20
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.

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, but that's not what the expiry date in the leaf certificates they issue you is about.

Nor is it intended that the lifetime of a certificate reflects the expected time to break the private key the user knows, otherwise Apple would let you have say a two year certificate if you went to P-384 certificates because they're harder to break in theory. There is obviously a threat over time that your keys leak ("Oops, the backup tapes I put in the trash have our current keys") but that's hard to assign a specific time interval to, it just means you should definitely change keys sometimes.

The main thing that we're always worried about on a specific timescale is the name information. The same people control google.com today as two years ago, and likewise for my.lovely.horse but how about bobs-exhausts.example ?

But the main impetus for desiring shorter lived certificates is that the certificate lifetime in practice constrains our ability to make technical changes like the SHA-1 deprecation. We'd like to make changes faster, and if you've just bought an 825 day certificate realistically our changes can't be effective in less than 825 days unless we're willing to be so disruptive your apparently valid cert ceases to work in popular browsers, which will be a hard thing to sell for merely precautionary changes.

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

#67

Post by tingletech »

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.

> Also browser should send their public key to the server!

That would make fingerprinting even easier?

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

#68

Post by Mister_Snuggles »

nimbius wrote: post #50
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

These both look really good! I'll have to check them out in more detail.

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

#69

Post by saagarjha »

njsubedi wrote: post #33
nicolas_t wrote: post #30

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.

Wouldn't it be a better idea to use alternate domains instead of subdomains? You could use something like [any subdomain].atdie8e73bhdbdie93ruhe.[any tld] for obfuscation?

Those cost money.

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

#70

Post by Mister_Snuggles »

dcow wrote: post #61
nimbius wrote: post #50

Earlier quoted context omitted.

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

CFSSL was developed with cloudflare-specific use cases in mind. If you're looking for a general purpose personal CA, checkout smallstep/certificates: https://github.com/smallstep/certificates . Full disclosure, I work for smallstep, but we’re not exactly competitors. Regardless, here’s an external analysis of the two: https://jite.eu/2020/2/17/step-ca/

This looks very nice too! I'll have to look at this one closely, it seems to give me most of what I'm looking for. Thanks!
Post reply on HN