Live data from Hacker News

CA Root expired on 30 May 2020

support.sectigo.com

81–90 of 154 posts

Re: CA Root expired on 30 May 2020

#81
post #56

Andrew Ayer has a write-up about this at https://www.agwa.name/blog/post/fixing_the_addtrust_root_exp... At the core, this is not a problem with the server, or the CA, but with the clients. However, servers have to deal with broken clients, so it’s easy to point at the server and say it was broken, or to point at the server and say it’s fixed, but that’s not quite the case. I discussed this some in https://twitter.co…

Given you mention OpenSSL is currently terrible at verifying "real" certificates: why doesn't e.g. Google just throw a bit of money at them and fix their bugs when they're clearly so well-known? It seems like such an obvious thing to do for a company whose entire business is built on the web. Is there really too little benefit to justify the cost of the engineer(s) it would take even for big companies? Or are the projects somehow blocking help?

Re: CA Root expired on 30 May 2020

#82
post #20

Quick reminder from your friendly local SRE: never ever issue certificates that expire on weekends. Make certs expire in the middle of the afternoon on a business day wherever your operators live and work. The cert in question expires at May 30 10:48:38 2020 GMT, which smells suspiciously like a fixed time after the cert was generated, rather than at a well-chosen point in time.

If you get to the point where the exact expiration date on the certificate matters, you've already lost the game.

Engineering for failure is important, you should always set yourself up so that you have several lines of defence which can fail. Some lines of defence to make failing "impossible" others to make a fail softer, even when you think failing is impossible.

Re: CA Root expired on 30 May 2020

#83
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…

Search for “Needham & Schroeder”

It’s not either/or expiration vs revocation; they are the same thing. Expiration is natural revocation and a ceiling function to the overall cost.

The statement “when a CA’s root certificate expires, it creates a new one” is not a general statement. That’s the exception, rather than the rule, as evidenced by just watching the changes to root stores over the past 30 years. More CAs have left the CA business / folded / been acquired than have carried on. A classic example of this is the AOL root, for which the long-standing scuttlebutt is that no one knows what happened to the key after AOL exited the CA business. The reason it’s scuttlebutt, as opposed to being a Sky is falling DigiNotar, is that the certificate expired. Or, for that matter, look at how many CAs have been distrusted. Expiration fits as a natural bound for legacy software that doesn’t receive updates, failing-secure rather than failing insecurely.

Re: CA Root expired on 30 May 2020

#84
Are we going to experience the same bug next year for all LetsEncrypt certificates when the DST Root CA X3 expires? I guess modern devices could deal with LetsEncrypt issuing directly from their own modern ISRG Root X1, but would that leave legacy clients completely stranded (iOS <10, older versions of Windows and Android...?)

Re: CA Root expired on 30 May 2020

#85
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…

Expiration may be useful but how is expiration in 2038 useful?

It isn’t, but then again, in 1995 we might have said the same for expirations in 2015, and yet so, so many poorly managed CAs were expunged in the past 5 years.

A healthy root store would set revocation at a much more aggressive period; say, every five years. Every three years, the CA applies to have their new root trusted, which gives two years to distribute that root to clients that need it, while having the old root sign the new root, to support an immediate transition to the new root. Among other things, this encourages a more robust and healthy CA ecosystem, because you don’t end up with lopsided balances based on “who has the oldest root.” That imbalance encouraged poor behavior which got CAs distrusted, in the past, because they behaved in a manner that assumed they were too big, by virtue of being too ubiquitous, to fail.

Re: CA Root expired on 30 May 2020

#86

Earlier quoted context omitted.

If you get to the point where the exact expiration date on the certificate matters, you've already lost the game.

it’s more like blue m&m’s than an actual requirement

>it’s more like blue m&m’s than an actual requirement

Did you mean Van Halen's famous "WARNING: ABSOLUTELY NO BROWN M&Ms" clause?

https://www.snopes.com/fact-check/brown-out/

Re: CA Root expired on 30 May 2020

#87
post #56

Andrew Ayer has a write-up about this at https://www.agwa.name/blog/post/fixing_the_addtrust_root_exp... At the core, this is not a problem with the server, or the CA, but with the clients. However, servers have to deal with broken clients, so it’s easy to point at the server and say it was broken, or to point at the server and say it’s fixed, but that’s not quite the case. I discussed this some in https://twitter.co…

Given you mention OpenSSL is currently terrible at verifying "real" certificates: why doesn't e.g. Google just throw a bit of money at them and fix their bugs when they're clearly so well-known? It seems like such an obvious thing to do for a company whose entire business is built on the web. Is there really too little benefit to justify the cost of the engineer(s) it would take even for big companies? Or are the pro…

Google has, in the past. Look at the ChangeLog for 1.0.0 - the massive improvements made (around PKITS) were sponsored by Google.

Google has a healthy Patch Rewards program ( https://www.google.com/about/appsecurity/patch-rewards/ ) that rewards patches to a variety of Open Source Projects.

Google also finds a variety of projects through the Core Infrastructure Initiative ( https://www.coreinfrastructure.org/ ), which OpenSSL is part of https://www.coreinfrastructure.org/announcements/the-linux-f...

Re: CA Root expired on 30 May 2020

#89
post #20

Quick reminder from your friendly local SRE: never ever issue certificates that expire on weekends. Make certs expire in the middle of the afternoon on a business day wherever your operators live and work. The cert in question expires at May 30 10:48:38 2020 GMT, which smells suspiciously like a fixed time after the cert was generated, rather than at a well-chosen point in time.

Also make a Calendar placeholder (like a fake meeting), invite a lot of folks or a distribution list, and turn on an alert for 24 hours ahead.

For long-lived certificates they will outlive your calendar tech. The bit rot leave maybe the events fine, but anything fancier like notifications will fad away.

Source: BTDT 3 times in 7 years, and it was all with "Big Enterprise" grade products.

Re: CA Root expired on 30 May 2020

#90
post #20

Quick reminder from your friendly local SRE: never ever issue certificates that expire on weekends. Make certs expire in the middle of the afternoon on a business day wherever your operators live and work. The cert in question expires at May 30 10:48:38 2020 GMT, which smells suspiciously like a fixed time after the cert was generated, rather than at a well-chosen point in time.

"Middle of the afternoon" .. for who?
Post reply on HN