Live data from Hacker News

CA Root expired on 30 May 2020

support.sectigo.com

71–80 of 154 posts

Re: CA Root expired on 30 May 2020

#71
post #61

Earlier quoted context omitted.

Exactly. Certificate expiration has never really been about security. It's purely for practicality, so that CRLs won't grow without bound. This is especially true now that we have OCSP stapling. From a security perspective, a short-lived certificate is exactly equivalent to a long-lived certificate with mandatory OCSP stapling and a short-lived OCSP response, but the latter is much more complicated. And in this case…

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?

Re: CA Root expired on 30 May 2020

#73
post #59

Earlier quoted context omitted.

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" cert…

There's actually a third certificate for "USERTrust RSA Certification Authority", also using the same key pair, signed by a different root called "AAA Certificate Services". It looks like the intended replacement for the expiring one is this one, rather than the one where it's the root itself.

It is explicitly not a replacement, but some kind of legacy fallback that they don't want you to use, but exists for enterprise customers that absolutely can't get trust.

Re: CA Root expired on 30 May 2020

#74
post #73

Earlier quoted context omitted.

There's actually a third certificate for "USERTrust RSA Certification Authority", also using the same key pair, signed by a different root called "AAA Certificate Services". It looks like the intended replacement for the expiring one is this one, rather than the one where it's the root itself.

It is explicitly not a replacement, but some kind of legacy fallback that they don't want you to use, but exists for enterprise customers that absolutely can't get trust.

Are you sure? That's the path that InCommon has been providing me for new certificates since they switched away from the expiring one.

Re: CA Root expired on 30 May 2020

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

Is that a cURL bug?

It seems only to be older versions of curl or curl with openssl <= 1.1.1. My macbook's curl fails, but my arch linux box's curl works fine.

Re: CA Root expired on 30 May 2020

#76
I was wondering why Lynx started spouting some nonsense:

    $ lynx -dump https://wiki.factorio.com/Version_history
    
    Looking up wiki.factorio.com
    Making HTTPS connection to wiki.factorio.com
    SSL callback:certificate has expired, preverify_ok=0, ssl_okay=0
    Retrying connection without TLS.
    Looking up wiki.factorio.com
    Making HTTPS connection to wiki.factorio.com
    SSL callback:certificate has expired, preverify_ok=0, ssl_okay=0
    Alert!: Unable to make secure connection to remote host.
    
    lynx: Can't access startfile https://wiki.factorio.com/Version_history

Re: CA Root expired on 30 May 2020

#77
post #38
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…

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

Re: CA Root expired on 30 May 2020

#78

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.

Same exact thing happened to me (Namecheap, PositiveSSL, renewed roughly a month ago). I went the reissue route on Namecheap and that fixed it (and I ended up with a certificate chain that is one certificate shorter).

Re: CA Root expired on 30 May 2020

#79
post #38
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…

I've used this https://manpages.debian.org/testing/nagios-plugins-contrib/c...

After one scrambling emergency with a cert expiring in the middle of the day, a constant check with warnings and alerts a couple of weeks before expiry made a matter of defensive organization into something trivial.

Re: CA Root expired on 30 May 2020

#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..
Post reply on HN