The current certificate chain that LetsEncrypt's certbot install, is invalid. This chain creates all sorts of issues with vulnerability scanners that we now have to address. We cannot rely on client-side devices to verify the chain of trust.
Please provide a valid chain of trust that will automatically install onto our servers.
@francoisj , welcome to the community!
The default certificate chain provided be Letsencrypt should be fine for most cases. Known exception is having some old openssl implementation that aborts searching for supplementary trust path when it encounters expired root certificate.
You may want to select the alternate chain that does not contain the certificate pointing to the expired root certificate. However, you may loose old android phone compatibility.
Anyhow, may be an update for the vulnerability scanner could help to remove the incorrectly reported issue?
The vulnerability scanners are wrong. There are a few previous threads on the forum if you search around which have some tools complaining about the root certificate that Let's Encrypt's default chain uses, but a lot of careful thought and work went into the choice of chain, to maximize compatibility with as many devices as possible.
As mentioned, you have the option to use the alternate chain with Certbot which chains only to the modern "ISRG Root X1" root:
That said, will LE be bothering to renew the current ISRG Root X1 cross signed by DST Root CA X3, expiring Sept 2024?
For the next release of our app we're planning to default to preferring the ISRG Root X1 chain for LE because it doesn't really make much sense on Windows and causes confusion when people export their cert chain to other devices/certificate stores. I'm not sure if we have current stats for the number of devices still in circulation which require the DST Root CA X3 workaround but perhaps clients could set this as their preferred chain, rather than having it as the default.
But isn’t DST Root CA X3 expiring? The self-signed certificate which represents the DST Root CA X3 keypair is expiring. But browser and OS root stores don’t contain certificates per se, they contain “trust anchors”, and the standards for verifying certificates allow implementations to choose whether or not to use fields on trust anchors. Android has intentionally chosen not to use the notAfter field of trust anchors. Just as our ISRG Root X1 hasn’t been added to older Android trust stores, DST Root CA X3 hasn’t been removed. So it can issue a cross-sign whose validity extends beyond the expiration of its own self-signed certificate without any issues.