Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s Encrypt DST Root CA X3 Expiration – September 2021

letsencrypt.org

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#31

Post by hannob »

josephcsible wrote: post #26
hannob wrote: post #23

Earlier quoted context omitted.

Ain't gonna happen. Let's Encrypt is too big to be ignored. You can't practically use the web like that.

We know this, but I don't think everyone does. I'm sure that at least some places will learn this the hard way.

Maybe we just had a misunderstanding. What I was trying to say: Once this happens and everything breaks they will have an incentive to fix things quickly.

By no means do I expect vendors of "SSL inspection" devices to act any sooner than that.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#32

Post by gregoriol »

crazypython wrote: post #24
currysausage wrote: post #15

Earlier quoted context omitted.

Basically ZeroSSL and Buypass, yes. Buypass certificates have the additional benefit of being valid for 180 days. The rate limits are a bit stricter than with Let's Encrypt, I believe: https://www.buypass.com/ssl/resources/go-ssl-technical-speci...

I assume they are more trusted by older devices than Let's Encrypt. Source?

Not sure its reliable but I've found this comparison: https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#33

Post by kstrauser »

selfhoster11 wrote: post #27
kstrauser wrote: post #19

Earlier quoted context omitted.

To a point. The environmental footprint of a 486 tower system today would be much higher than modern system because the humans that use it more slowly and who have to maintain it use a lot more resources.

Given lightweight software, a 486 tower is usable indefinitely with a zero environmental footprint as long as the electricity comes from a sustainable source (such as solar).

It is as long as you don’t consider the footprint of the person using it. If it runs more slowly than a modern system such that a human has to spend more time working with it, then it’s almost certainly less resource friendly.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#34

Post by Deathmax »

crazypython wrote: post #24
currysausage wrote: post #15

Earlier quoted context omitted.

Basically ZeroSSL and Buypass, yes. Buypass certificates have the additional benefit of being valid for 180 days. The rate limits are a bit stricter than with Let's Encrypt, I believe: https://www.buypass.com/ssl/resources/go-ssl-technical-speci...

I assume they are more trusted by older devices than Let's Encrypt. Source?

ZeroSSL's current RSA intermediate is https://crt.sh/?id=2427368505, which chains up to USERTrust RSA Certification Authority (https://crt.sh/?caid=1167).

I was going to migrate over to ZeroSSL, but there were red flags in the form of missing documentation that you would expect from a CA, like what is the chain of trust for certificates that are being issued? If I have to issue myself a certificate to check which CA is being used to sign the cert, that doesn't feel right.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#35

Post by alias_neo »

jeroenhd wrote: post #13
aisio wrote: post #9

Earlier quoted context omitted.

Many enterprises use a FIPS SSL proxy for all employees web traffic, so all websites with these lets encrypt will effectively be invalidated if the proxies are using openssl FIPs modules, same for FIPS client side applications

It seems quite silly to me to enforce a massive MitM attack while at the same time sticking to the FIPS standards. Then again, a lot of governmental and financial security requirements are nonsensical to me, like mandatory password changes. When I, as a website host, need to choose between accepting millions of Android devices or a few organizations with an esoteric security configuration, I'll go for the Android dev…

Some of it is misguided, some of it is legacy, other parts _do_ make sense to the people involved.

Mandatory password changes for example have not been recommended[0] by NCSC in the UK since ~2018. Continuing to do so is either legacy or misguided.

As for "MitM" it's usually due to regulatory requirements to protect and inspect at boundaries to and from an organisations network.

FIPS and OpenSSL is an interesting subject. Many organisations rely on it, yet relatively few contribute financially. When 1.1.X and subsequent versions came along and had no FIPS 140-2, orgs were forced to wait it out until someone else pays to get it accredited or pony up and help the process along. I haven't looked lately at how much has been contributed to the effort but I suspect it's still pretty low considering how much of the world relies on OpenSSL.

[0]https://www.ncsc.gov.uk/collection/passwords/updating-your-a...

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#36

Post by Wowfunhappy »

kstrauser wrote: post #19
fnord77 wrote: post #3

Earlier quoted context omitted.

and a bad thing for e-waste.

To a point. The environmental footprint of a 486 tower system today would be much higher than modern system because the humans that use it more slowly and who have to maintain it use a lot more resources.

I don't understand. The human wouldn't cease to exist regardless of how fast or slow their computer is, right?

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#37

Post by tialaramex »

crazypython wrote: post #24
currysausage wrote: post #15

Earlier quoted context omitted.

Basically ZeroSSL and Buypass, yes. Buypass certificates have the additional benefit of being valid for 180 days. The rate limits are a bit stricter than with Let's Encrypt, I believe: https://www.buypass.com/ssl/resources/go-ssl-technical-speci...

I assume they are more trusted by older devices than Let's Encrypt. Source?

I suspect there is no source that tracks exactly what's trusted on a large range of devices. Perhaps somebody should maintain this information, although it seems like a really thankless volunteer task, I'm really interested in such stuff and still it makes me feel tired just thinking about it.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#38

Post by tptacek »

josephcsible wrote: post #12
tux3 wrote: post #7

Earlier quoted context omitted.

Isn't the point of FIPS accreditation that the organization wants to prioritize compliance over functionality/security? A FIPS device being unpatched or broken for a few months almost seems like the natural state of things, at this point.

Yes, 100% this. The best evidence is probably that Dual_EC_DRBG got FIPS approval, but ChaCha20/Poly1305 and Curve25519 have not.

https://csrc.nist.gov/publications/detail/fips/186/5/draft

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#39

Post by Spivak »

ses1984 wrote: post #6
fnord77 wrote: post #3

Earlier quoted context omitted.

and a bad thing for e-waste.

Devices that can’t be updated all face an early ewaste destiny, don’t blame expiring certs.

This is kinda silly. These are problems that, as an industry, we make for ourselves. The fact that you can't make a network connected device that continues to function for decades without a constant maintenance is a problem not a feature.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#40

Post by Spivak »

josephcsible wrote: post #17
fnord77 wrote: post #16

Earlier quoted context omitted.

well maybe a trust system that forces devices that can't be updated into obsolescence is not a good system.

Maybe having devices that can't be updated is not a good system.

Having perfectly functional devices that become obsolete because the world moves around them is also not a good system. We don't have to design our support targets to be a moving window of >= $current_version - 2.
Post reply on HN