Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CA Root expired on 30 May 2020

support.sectigo.com

Post reply on HN
Print view View original

121–130 of 154 posts

Re: CA Root expired on 30 May 2020

#121

Post by toast0 »

josephcsible wrote: post #64
sleevi wrote: post #61

Earlier quoted context omitted.

It’s not true that expiration is not about security. Dan Geer’s talk in 1998, noted at https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html , is just as relevant today in the design of key management systems. Expiration is not “just” about cryptographic risk either; there are plenty of operational risks. If you’re putting your server on the Internet, and exposing a service, you should be worried about key comprom…

I don't see anything about expiration in that talk. If you don't have a strong revocation system, then your host is vulnerable whether or not you have expiration, since attackers aren't going to wait until the day before your key expires to try to steal it. In general, when a CA's root certificate expires, it creates a new one and gives it to browser and OS vendors. What's the difference between the CA continuing to…

> If you don't have a strong revocation system, then your host is vulnerable whether or not you have expiration, since attackers aren't going to wait until the day before your key expires to try to steal it.

We don't have a strong revocation system. Maybe one day OSCP stapling will be mandatory, although OSCP signatures are reusable within an expiration window, so we still have the question of expiration.

> In general, when a CA's root certificate expires, it creates a new one and gives it to browser and OS vendors. What's the difference between the CA continuing to guard their old private key, and starting to guard the new private key?

Their new key is fresh --- the public key hasn't been floating around being factored for the last 20 years. Maybe it's longer too. It certainly wouldn't be on disk of hardware they discarded before the new key was generated. Of course, they should have taken proper precautions with their discarded hardware, but maybe someone slipped up.

Frequent expiration is a way of limiting the damage of key theft, not a way to prevent it. In some (many?) cases, key theft is not detected, so limiting the amount of time it could be used is helpful.

OTOH, what do you do for devices which are shipped with a CA bundle, and never updated. They may be a problem for other reasons, but at some point, they don't have any valid roots and they turn into a pumpkin. (Fun times if the manufacturer realizes and tries to update, but doesn't get the update distributed before the certs expire; there was an Amazon Kindle update like that once).

Re: CA Root expired on 30 May 2020

#122

Post by toast0 »

userbinator wrote: post #97

A bit of an aside, but While Android 2.3 Gingerbread does not have the modern roots installed and relies on AddTrust, it also does not support TLS 1.2 or 1.3, and is unsupported and labelled obsolete by the vendor. If the platform doesn’t support modern algorithms (SHA-2, for example) then you will need to speak to that system vendor about updates. I find things like that really really irritating. Crypto is basically…

You could ship better crypto (and updated CAs) with your app for Android -- then you could get support for whatever you like on all versions. But it might not use hardware acceleration if available, and hardware running Gingerbread needs crypto acceleration if available. TLS 1.3 isn't all that much code if you can use the system x.509 and system ciphers, or maybe pick one or two ciphers to ship if they're not there; I'd guess TLS 1.2 isn't that much code either, the complexity comes from trying to support lots of versions -- and from X.509 which has a lot of stuff to process.

I think Chrome for Android did include TLS 1.2 at least, when it was shipping for Gingerbread.

Re: CA Root expired on 30 May 2020

#123

Post by sjtindell »

user5994461 wrote: post #44
jeffbee wrote: post #26

Earlier quoted context omitted.

Of course, but that doesn't really excuse them. My first experience with middle-of-Sunday-night SSL certificate expiration was in December 1998, and it was already a well-known doctrine by then. I'd expect a commercial certificate authority to have these kinds of things squared away.

My experience with commercial CA is that they set the expiry exactly 1 year from creation. Doesn't matter if it's a week end or a holiday.

Generally that’s for Server certs, Roots and Intermediates will be multiple years from what I’ve seen. Roots in particular 10+ years.

Re: CA Root expired on 30 May 2020

#124

Post by Thorrez »

admax88q wrote: post #28

Honestly, certificates should never expire or should expire daily. If certificate revocation works then its pointless to have expiring certs. Its just a mechanism for CAs to seek rent. If certificate revocation doesnt work then certs need to expire super frequently to limit potential damage if compromised. A certificate that expires in 20 years does absolutely nothing for security compared to a certificate that never…

If I operate a website, I might have some confidence that my key hasn't been stolen in the last year. But I might have much less confidence that my key hasn't been stolen in the last 20 years.

Certificate expiration means I don't need to worry about that second case.

Re: CA Root expired on 30 May 2020

#125

Post by AmericanChopper »

pwdisswordfish2 wrote: post #118
AmericanChopper wrote: post #45

Earlier quoted context omitted.

It’s the PKI paradigm that creates most of the insanity. Authentication is still an unsolved issue with PKI, there’s many ways that you can perform authentication, but all of the different approaches lead to one form of insanity or another. The CA system has its share of insanity, but it is the most successful PKI implementation in history, and by a long way.

PKI authentication is only insane when delegated to a third party. There is a built-in assumption within the CA system that no two parties can ever trust each other and intermediaries are always needed. A world of strangers who never learn anything about or get to know each other. It is either impractical or impossible for the first party to trust the second, using this system, without third party intervention. What…

Well you can’t perform authentication over an insecure channel, and you can’t have a secure channel without authentication. Either you trust an authority, or you authenticate manually yourself. There’s a reason TLS uses the CA system, and not PGP.

Re: CA Root expired on 30 May 2020

#126

Post by Thorrez »

Sphax wrote: post #7
encoderer wrote: post #2

I have never really wanted to go "serverless" until today. TIL that I can buy a cert that expires in a year that is signed by a root certificate that expires sooner. Still not sure WHY this is the case, but this is definitely the case.

As far as I understand your certificate is still valid but you need to remove the intermediate certificate from your bundle. That was the case for me anyway.

You only need to remove the cert if you want to support buggy clients. If none of your clients are buggy, it will be fine to leave the expired cert in the chain.

Re: CA Root expired on 30 May 2020

#127

Post by pwdisswordfish2 »

AmericanChopper wrote: post #125
pwdisswordfish2 wrote: post #118

Earlier quoted context omitted.

PKI authentication is only insane when delegated to a third party. There is a built-in assumption within the CA system that no two parties can ever trust each other and intermediaries are always needed. A world of strangers who never learn anything about or get to know each other. It is either impractical or impossible for the first party to trust the second, using this system, without third party intervention. What…

Well you can’t perform authentication over an insecure channel, and you can’t have a secure channel without authentication. Either you trust an authority, or you authenticate manually yourself. There’s a reason TLS uses the CA system, and not PGP.

You can authenticate outside of the insecure channel. There is a real world outside of the internet.

It is this "manual authentication" that the CA system does not account for. It is not an option. Why is it that, in practice, the only certificates an end user's "CA" can sign are the end user's server certificates?

Re: CA Root expired on 30 May 2020

#128

Post by AmericanChopper »

pwdisswordfish2 wrote: post #127
AmericanChopper wrote: post #125

Earlier quoted context omitted.

Well you can’t perform authentication over an insecure channel, and you can’t have a secure channel without authentication. Either you trust an authority, or you authenticate manually yourself. There’s a reason TLS uses the CA system, and not PGP.

You can authenticate outside of the insecure channel. There is a real world outside of the internet. It is this "manual authentication" that the CA system does not account for. It is not an option. Why is it that, in practice, the only certificates an end user's "CA" can sign are the end user's server certificates?

> You can authenticate outside of the insecure channel. There is a real world outside of the internet.

Exactly, and you can look at how much of a failure PGP has been to see how successful that approach is.

> Why is it that, in practice, the only certificates an end user's "CA" can sign are the end user's server certificates?

CAs can sign any X.509 certificate. They only authenticate domain control or business ownership (via “EV”), though. CA certs also aren’t only used for TLS. You can get a code signing cert from a CA for instance.

You can write a very long list of perfectly valid complaints about the CA system. However it is undeniably the most successful PKI ever implemented, and not just by a little bit.

This isn’t because CAs are bad at what they do. It’s because there is absolutely no elegant solution to that problem. If you want to authenticate identity manually, then I wish you luck finding one or two other people to join you. If you want to securely communicate with people you don’t know personally, or who don’t know how to/can’t be bothered to maintain their own set of private keys, then you’re going to need to establish trust via a 3rd party authority.

Re: CA Root expired on 30 May 2020

#129

Post by emilburzo »

Sebb767 wrote: post #96
kl4m wrote: post #77

Earlier quoted context omitted.

Good old "cert replaced but apache/nginx failed to reload" has bitten me more than once...

Me too! Especially with the short expiration times of LetsEncrypt. But I really don't want to put `nginx -s reload` in the Cron, in case I'm tinkering with the configs and they're suddenly live (which only really happens at staging or at home of course, but still).

You can use `nginx -t && nginx -s reload` for that.

It will first check the configs/paths, and only then, if successful, signal nginx to reload.

Re: CA Root expired on 30 May 2020

#130

Post by oarsinsync »

Thorrez wrote: post #124
admax88q wrote: post #28

Honestly, certificates should never expire or should expire daily. If certificate revocation works then its pointless to have expiring certs. Its just a mechanism for CAs to seek rent. If certificate revocation doesnt work then certs need to expire super frequently to limit potential damage if compromised. A certificate that expires in 20 years does absolutely nothing for security compared to a certificate that never…

If I operate a website, I might have some confidence that my key hasn't been stolen in the last year. But I might have much less confidence that my key hasn't been stolen in the last 20 years. Certificate expiration means I don't need to worry about that second case.

That’s only true if your key is regenerated each time you request an updated certificate. This is not mandatory, and there are lots of guides on the internet for generating a csr from an existing key.
Post reply on HN