Live data from Hacker News

CA Root expired on 30 May 2020

support.sectigo.com

91–100 of 154 posts

Re: CA Root expired on 30 May 2020

#91
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.

> rather than at a well-chosen point in time

So, you're saying that "I'm not going to be working here anymore by then... hahahaha" isn't well-chosen?

Re: CA Root expired on 30 May 2020

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

If you're going to ask a question about someone's comment, at least finish reading the sentence to make sure it's not immediately answered.

Don't be part of the death of internet discourse.

Re: CA Root expired on 30 May 2020

#93
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.

Great tip. Did you notice that cert in this case was issued 20 years ago? It’s crazy to me that it was still being used to sign certs as recently as last week (according to twitter)

> It’s crazy to me that it was still being used to sign certs as recently as last week (according to twitter)

It's likely because it was issued 20 years ago. People have been using it for 20 years and no-one realized it was about to stop working.

Re: CA Root expired on 30 May 2020

#94
post #83

Earlier quoted context omitted.

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

When I search for that, all of my hits are about a key-transport protocol that doesn't seem related to certificates at all.

Expiration and revocation are far from the same thing. If my site's private key gets stolen, I want clients to stop trusting it today, not next year.

Expiring roots means that if a device stops getting updates from its vendor, it will gradually become a brick even if no CAs do anything wrong.

Re: CA Root expired on 30 May 2020

#95
post #80

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…

What if your CA is down for a day? Imagine let's encrypt being down for 24 hours and all if it's certificates going invalid. That would be millions of websites unavailable..

This is no different than an OCSP server going down for a day. Either the site becomes unreachable, or clients take a risk by accepting a certificate that might be revoked.

Re: CA Root expired on 30 May 2020

#96
post #77
post #38

Earlier quoted context omitted.

All my applications use a component that watches certs configured (everything in cert and trust store) and returns warning in telemetry from the application if any of the certificates is less than a week from expiration. This is checked periodically while the application runs. This not only makes sure we don't miss expiration but also ensures we don't forget to configure any of the application. We had a situation whe…

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

Re: CA Root expired on 30 May 2020

#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 maths, and a very pure form at that, so should be one of the most portable types of software in existence. Computers have been doing maths since before they were machines. Instead, the forced obolescence bandwagon has made companies take this very pure and portable technology and tied it to their platform's versions, using the "security" argument to bait and coerce users into taking other unwanted changes, and possibly replacing hardware that is otherwise functional (and, as mentioned earlier, is perfectly capable of executing the relevant code) along with all the ecological impact that has. Adding new root certificates at least for PCs is rather easy due to their extreme portability, but I wish the same could be said of crypto algorithms/libraries.

Re: CA Root expired on 30 May 2020

#98

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're mad at the wrong people. The security argument is legitimate, so there's no need for your scare quotes. The weaknesses in TLS older than 1.2 are real. You should instead be upset at device vendors for deciding to drop support for devices so quickly. If they'd just keep supplying updates, or even open-source everything so the community could, then this wouldn't be an issue.

Re: CA Root expired on 30 May 2020

#99

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…

These days, Android 2.3 Gingerbread devices are essentially obsolete even from a strictly hardware point of view. Most of those were actually very well supported by the old CyanogenMod releases, but few people would even bother trying to bring up something reasonably modern like pmOS by building on that work, the specs are just that bad.

Re: CA Root expired on 30 May 2020

#100
post #43

This one bit me today and abruptly ended my day at the beach. The certificate reseller advised my customer that it was okay to include the cross-signing cert in the chain, because browsers will automatically ignore it once it expires, and use the Comodo CA root instead. And that was true for browsers I guess. But my customer also has about 100 machines in the field that use cURL to access their HTTPS API endpoint. cU…

HTTP clients in programming languages are not as smart as web browsers when it comes to verifying SSL certificate chains. For example, if the chain presented by the server is missing intermediate certificates, modern web browsers are able to fetch those intermediate certificates without issue. Most HTTP clients do not do that though, and instead will throw a cryptic error, something along the lines of "unable to get local issuer certificate". This is known as a 'incomplete chain' error.

Earlier this year I added SSL verification to a website uptime monitoring service I run (https://www.watchsumo.com/docs/ssl-tls-monitoring) and it wasn't anywhere near as simple as I thought it would be. There's so many edge cases regarding verification, and languages usually don't expose the full errors in exceptions, then you have errors like this which only affect a subset of clients.

Post reply on HN