Let's Encrypt DST Root CA X3 Expiration

[raf]

On Sat, Oct 02, 2021 at 10:32:40PM -0500, Ryan Schmidt <ryandesign at macports.org> wrote:

> On Oct 2, 2021, at 22:06, Michael wrote:
> > 
> > So, first, I want to say "Thank you" for this bit:
> > 
> >> • From View menu select "Show Expired Certificates"
> > 
> > In keychain access, I could not see the expired certs, and was thinking that they were just deleted for being old. Once I could find the old ones, I could turn them back on.
> > 
> > The second thing is that for whatever reason, I could not download and install the new cert into keychain access. But ... oddly, Firefox 52 ESR had that cert installed (even that old ...???). I could export from firefox, and import THAT into keychain access, and at least enable that for my account.
> > 
> > So, ... well, not perfect. These certs are marked as trusted for *my account*. Not for the system. So predictably, some things done by the system in the background will fail, but at least Chrome and Firefox both now work fine. (Safari isn't tested, but ... well, Safari isn't tested :=-).
> > 
> > ====
> > 
> > I have a much better question, that's outside of the scope of this
> > list or even the site(s) in question.
> > 
> > Why does a signature expire?
> > 
> > If I have something that was signed by a cert, and it was signed in
> > a valid time time stamp, why does that signature ever expire?
> > 
> > I've come across programs that have an expired signature, and I
> > can't see a good reason for it.
> > 
> > And if there's no good way to tell when something was actually
> > signed (because a timestamp can be forged), then the question
> > becomes, why does a cert expire as a function of time? Why not allow
> > a cert to be "until revoked"?
> > 
> > For that matter, why is "valid/not valid" not under the control of
> > the system? Why is someone else allowed to say that my system is no
> > longer valid?
> > 
> > I figure that there's a good answer to these questions somewhere,
> > but I have no clue where to even begin looking. And yes, I know
> > that quantum factoring will eventually permit all of these certs to
> > be forged, but until then, why not allow them, and even after that
> > point, why not allow me to allow them?
> 
> I'm not an expert on this stuff, just sharing what I learned about the
> issue yesterday, but you can ask your search engine questions like
> "why do certificates expire" or more specifically in this case "why do
> root ca certificates expire".
> 
> My understanding is that the reason why Let's Encrypt recommends sites
> continue to serve the ISRG Root X1 certificate that is signed by the
> expired DST Root CA X3 certificate is that at least old browsers like
> those on old Android phones should consider a web site's certificate
> to be valid, as long as we are within its validity dates, even if
> the root certificate it's signed by is expired. Like I said, I'm not
> an expert, I don't know why it would be that way, and evidently it's
> not that way on some Apple devices, so server administrators now have
> to choose between Let's Encrypt's default which supports old Android
> devices or the other way which supports old Apple devices.

The instructions
https://trac.macports.org/wiki/ProblemHotlist#letsencrypt
include a suggestion of asking other webserver
administrators to delete "DST Root CA X3" from their
full chain, and use --preferred-chain "ISRG Root X1"
when next renewing their LetsEncrypt certificate, so
that those sites will work with macOS 10.{4-7,13,14}.
This would result in the loss of access by old Android
devices. Each webserver administrator would have to
decide which clients are more important. Obviously, for
macports.org, the old macOS clients are more important.

The reason that there is a difference is just that
different TLS software implements things differently,
both different implementations, and different versions
of the same implementation. Old android assumes that
root certificates must be OK, and doesn't check if
they're expired (so keeping DST Root CA X3 works).
Others stop checking the chain as soon as it encounters
a certificate that is a local root certificate (so just
installing ISRG Root X1 locally on the client is
enough). Others keep checking the entire chain no
matter what (So DST Root CA X3 must either be removed
from server chains, or its expiry must be overruled
locally on clients). As for why this is: maybe the
chain-checking algorithm wasn't standardised (don't
know), or each approach just seemed like a good idea at
the time. :-)

cheers,
raf