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

101–110 of 154 posts

Re: CA Root expired on 30 May 2020

#101

Post by dylz »

josephcsible wrote: post #74
dylz wrote: post #73

Earlier quoted context omitted.

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.

On anything with a modern TLS stack, I see this trust chain:

- Leaf cert (your cert)

- InCommon RSA Server CA

- USERTrust RSA Certification Authority (this is/should be the final point)

Re: CA Root expired on 30 May 2020

#102

Post by viraptor »

Mojah wrote: post #5

This issue is largely cause by people still stuffing old root certificates in their certificate chains, and serving that to their users. As a general rule of thumb: 1) You don't need to add root certificates to your certificate chain 2) You especially don't need to add expired root certificates to the chain For additional context and the ability to check using `openssl` what certificates you should modify in your cha…

It depends what clients you need to support. ssllabs test for the server will tell you which ones you're compatible with. You may get some surprises with old Androids and XP. (whether you're interested in being available to them is another question)

Re: CA Root expired on 30 May 2020

#103

Post by aarmenaa »

seibelj wrote: post #6

DataDog failed this morning because of root CA issue.[0] Was a fun Saturday morning with 5000 alarms blowing up my phone. [0] https://status.datadoghq.com/incidents/6bqpd511nj4h

Datadog has shit the bed for us multiple times in the last six months. Unannounced breaking API changes, unaddressed bugs, and now their embedded cert expired.

Our org is currently divided over further commitment to the service, or leaving them entirely. They've made it very hard to argue in their favor.

Re: CA Root expired on 30 May 2020

#104

Post by jldugger »

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.

> Make certs expire in the middle of the afternoon on a business day wherever your operators live and work.

If I can predict that 20 years into the future I wouldn't be in the SRE business.

Re: CA Root expired on 30 May 2020

#105

Post by josephcsible »

dylz wrote: post #101
josephcsible wrote: post #74

Earlier quoted context omitted.

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

On anything with a modern TLS stack, I see this trust chain: - Leaf cert (your cert) - InCommon RSA Server CA - USERTrust RSA Certification Authority (this is/should be the final point)

That's what my browser shows me too, but it's just because it's ignoring the cross-signed one that chains to AAA. The server is sending it, per InCommon's setup instructions.

Re: CA Root expired on 30 May 2020

#106

Post by jeffbee »

jldugger wrote: post #104
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.

> Make certs expire in the middle of the afternoon on a business day wherever your operators live and work. If I can predict that 20 years into the future I wouldn't be in the SRE business.

I think it was foreseeable even in dark days of the year 2000 that this certificate expired after business hours globally.

But your statement is really pointing out that nobody should be making long-lived certificates.

Re: CA Root expired on 30 May 2020

#107

Post by dredmorbius »

jakub_g wrote: post #54
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.

Unfortunately, given crypto algo evolution and Moore's Law, the reverse is more likely true. Though that would be a neat hack.

Re: CA Root expired on 30 May 2020

#109

Post by solarengineer »

jldugger wrote: post #104
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.

> Make certs expire in the middle of the afternoon on a business day wherever your operators live and work. If I can predict that 20 years into the future I wouldn't be in the SRE business.

If you were to issue certs for short durations, and also maintain a calendar of cert expiry, those certs could be renewed in a timely manner.

In other scenarios where one would want to issue fresh certificates (receiving Ops control from other orgs, credentials refresh for what ever reason), one can still do so without waiting for the current certificates to expire.

Re: CA Root expired on 30 May 2020

#110

Post by tialaramex »

josephcsible wrote: post #105
dylz wrote: post #101

Earlier quoted context omitted.

On anything with a modern TLS stack, I see this trust chain: - Leaf cert (your cert) - InCommon RSA Server CA - USERTrust RSA Certification Authority (this is/should be the final point)

That's what my browser shows me too, but it's just because it's ignoring the cross-signed one that chains to AAA. The server is sending it, per InCommon's setup instructions.

That's correct

The old TLS (versions 1.0, 1.1, 1.2) specifications said that the certificates supplied are to form a chain, starting from a leaf and leading back towards a root.

Pretty much all clients assume that once they can see a way to a root they trust they'll give up following the provided chain and trust that - but sadly not all of them, so "over-specifying" the chain can cause problems.

Modern clients tend to go further, they still assume the first certificate is a leaf, but all other certificates are just potential hints that might be helpful in working out an acceptable trust path. TLS 1.3 actually specifies that clients must tolerate certificates supplied on this basis rather than a strict "chain".

I'm actually surprised at the number of claimed clients which don't have vaguely modern trust stores but do understand SHA256.

Post reply on HN