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

51–60 of 154 posts

Re: CA Root expired on 30 May 2020

#51

Post by josephcsible »

user5994461 wrote: post #46
josephcsible wrote: post #40

Earlier quoted context omitted.

IMO, there's a bit of a design flaw with curl here. There should be an easy flag to say "trust the particular certificate with this hash, no matter what's wrong with it", but there isn't, so people instead use the one that says "trust whatever certificate you get, no matter what's wrong with it".

Trusting a specific hash would blow up when the service rotate its self-signed certificate, defeating the point of ignoring certificate error.

If you're rotating a self-signed certificate, then how do you suppose that clients securely trust it? Or if you just mean replacing it when it expires, then this could instead be tied to the underlying public key alone, which can be reused.

Re: CA Root expired on 30 May 2020

#52

Post by dvdkhlng »

This just hit me via Debian's 'apt-get update': I'm using jitsi's package repository which is hosted via HTTPS and seems to rely on the expired root-CA. Certificate checks started failing for everybody a few hours ago [1].

That's quite bad, as I tried to do a clean re-install of jitsi-meet, and now I have no installation at all any more.

[1] https://github.com/jitsi/jitsi-meet/issues/6918

Re: CA Root expired on 30 May 2020

#53

Post by snapetom »

Yep. Got woken up early today for this. We renewed our cert about a month and two days ago. Namecheap, the vendor, sent us the bad AddTrust cert in the bundle. They weren't updating the bundles until two days after we renewed the cert.

Re: CA Root expired on 30 May 2020

#54

Post by jakub_g »

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…

Someone on Twitter (forgot whom, maybe swiftonsecurity?) suggested lately in a tongue-in-cheek way that the certs should not hard-expire, but instead add an exponentially-increasing slowdown at TLS handshake.

Once the slowdown is too big, someone will notice and have a look.

Re: CA Root expired on 30 May 2020

#55

Post by pixmin »

Everything is fine with PKI and SSL certificates. It was a bug in OpenSSL 1.0.1 / 1.0.2 in dealing with two times cross-signed root CA. It is fixed in 1.1.1, but these older versions are still default on RHEL6/RHEL7/Centos6/Centos7 and even Ubuntu16.04.

I think a large portion of online communications have been affected today.

Re: CA Root expired on 30 May 2020

#56

Post by sleevi »

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.com/sleevi_/status/1266647545675210753 , as clients need to be prepared to discover and explore alternative certificate paths. Almost every major CA relies on cross-certificates, some even with circular loops (e.g. DigiCert), and clients need to be capable of exploring those certificates and finding what they like. There’s not a single canonical “correct” certificate chain, because of course different clients trust different CAs.

Regardless of your CA, you can still do things to reduce the risk. Using tools like mkbundle in CFSSL (with https://github.com/cloudflare/cfssl_trust ) or https://whatsmychaincert.com/ help configure a chain that will maximize interoperability, even with dumb and old clients.

Of course, using shorter lived certificates, and automating them, also helps prepare your servers, by removing the toil from configuring changes and making sure you pickup updates (to the certificate path) in a timely fashion.

Tools like Censys can be used to explore the certificate graph and visualize the nodes and edges. You’ll see plenty of sites rely on this, and that means clients need to not be lazy in how they verify certificates. Or, alternatively, that root stores should impose more rules on how CAs sign such cross-certificates, to reduce the risk posed to the ecosystem by these events.

Re: CA Root expired on 30 May 2020

#57

Post by jis »

encoderer wrote: post #23
jeffbee wrote: 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 actually worse. The new root (good I believe until 2038) uses the same key as the now expired certificate. It has to or it would not be possible to validate the certificates that were issued. And this new one is a root certificate installed in browsers!

What "should" happen is that no certificate should be issued with an expiration date later than the issuing certificate. Then as the issuing certificate gets closer to expiration, a new one, with a new key pair, should be created and this new certificate should sign subordinate certificates.

Re: CA Root expired on 30 May 2020

#58

Post by donmcronald »

0x0 wrote: post #49
LeonM wrote: 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…

Sounds like a good test case for exercising those otherwise useless "million dollar insurances" that some certificate vendors flash in their sales materials?

Have you ever read the terms? I don't know if they even publish them anymore, but I read one many years ago. TLDR;

1. The CA must misissue a cert.

2. The misissued cert is used by a malicious party to impersonate you.

3. Every user (your users) must prove their damages and claim individually.

4. There might have been a low maximum, per-user claim, but I can't remember.

I'd be amazed if there's a single person on the internet who's been paid out by that warranty.

Re: CA Root expired on 30 May 2020

#59

Post by jis »

jis wrote: post #57
encoderer wrote: post #23

Earlier quoted context omitted.

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 actually worse. The new root (good I believe until 2038) uses the same key as the now expired certificate. It has to or it would not be possible to validate the certificates that were issued. And this new one is a root certificate installed in browsers! What "should" happen is that no certificate should be issued with an expiration date later than the issuing certificate. Then as the issuing certificate gets clo…

Sorry to reply to my own comment. But I want to clarify. Two certificates (at least) expired. The root named "AddTrust External CA Root" and a subordinate certificate with a subject of "USERTrust RSA Certification Authority." Both expired around the same time.

The "USERTrust RSA Certification Authority" certificate signed yet another layer of intermediate certificates.

The "USERTrust RSA Certification Authority" certificate was promoted to a self-signed certificate, now in the browser trust stores, using the same key pair as the original certificate that was signed by "AddTrust External CA Root." It has an expiration of 2038 (although that concept is a bit vague in a root certificate).

Re: CA Root expired on 30 May 2020

#60

Post by BurningFrog »

lmilcin wrote: post #38
jeffbee wrote: 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.

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…

There is just no substitute for Reality!
Post reply on HN