Hmm. I do think you're correct, at least in theory, but somehow we had DST certs in the path that got built. I forget the exact details of the two — I think it is the — R3 certs at that time.
All I know is that apt (through GnuTLS) stopped being able to install, and it was a massive headache. We upgraded to Bullseye (where apt seemed to not have whatever bug ailed it) at that time, and that fixed things.
One would think the Authority Key ID info would be the only thing that could define a path up the tree. There's also an option in ACME to get "alternate" chains, and I forget which chain was the alternate at the time. (I feel like it might have been the non-DST one, b/c the DST one was being preferred to get compatibility w/ Android, who would not realize the cross had expired, or something. But I also didn't learn about alternate chains in ACME until the expiration forced me to out of necessity.)
(I'm not sure how rigorous path building is, but the general state of TLS tooling leads me to believe it's a giant ball of yarn. Even since then, I have seen a bizarre apparent path to the expired DST root get built, although the circumstance in which I saw it afterwards was contrived, and involved a vendor (Hashicorp) adding a leaf (i.e., non-CA) cert to the list of CA certs, and doing it in such a way that leaves OpenSSL's internal structures in that dir corrupt. OpenSSL, in that situation, somehow, found the DST cert once again. Removing the leaf cert form the store caused the validation to succeed, but … OpenSSL's docs are not really clear about how you can or cannot screw about with its on-disk data. I call such shenanigans UB, and you reap what you sow, but I couldn't convince them of that. We lived with the issues that bug caused until it was apparently fixed in a later version.)
All I know is that apt (through GnuTLS) stopped being able to install, and it was a massive headache. We upgraded to Bullseye (where apt seemed to not have whatever bug ailed it) at that time, and that fixed things.
One would think the Authority Key ID info would be the only thing that could define a path up the tree. There's also an option in ACME to get "alternate" chains, and I forget which chain was the alternate at the time. (I feel like it might have been the non-DST one, b/c the DST one was being preferred to get compatibility w/ Android, who would not realize the cross had expired, or something. But I also didn't learn about alternate chains in ACME until the expiration forced me to out of necessity.)
(I'm not sure how rigorous path building is, but the general state of TLS tooling leads me to believe it's a giant ball of yarn. Even since then, I have seen a bizarre apparent path to the expired DST root get built, although the circumstance in which I saw it afterwards was contrived, and involved a vendor (Hashicorp) adding a leaf (i.e., non-CA) cert to the list of CA certs, and doing it in such a way that leaves OpenSSL's internal structures in that dir corrupt. OpenSSL, in that situation, somehow, found the DST cert once again. Removing the leaf cert form the store caused the validation to succeed, but … OpenSSL's docs are not really clear about how you can or cannot screw about with its on-disk data. I call such shenanigans UB, and you reap what you sow, but I couldn't convince them of that. We lived with the issues that bug caused until it was apparently fixed in a later version.)